Continuing a discussion that started in the DDD forum about how to display object in the UI layer, and a post from Sergio about his solution using the Builder pattern, I wanted to add a few thoughts to an already interesting issue.
First of all, I admit that the use of a Builder pattern doesn’t strike me as the best overall solution to all the view objects problems, but I liked the separation of concerns that it conveys. I would tend to keep the code away from the Façade because for me, the Façade is merely an entry point and a coordinator.
Maybe we could solve this problem as with any other domain related problem. I think we are guilty of focusing too hard on technical issues and wanting to solve the problem with a silver bullet instead of realizing that this is simply a different domain in which we, as developers, are the domain experts. Perhaps we have should try to face this issue having in mind that our existing model (Employees and Office) and our screen requirements are the data we have about this domain. In this context, each use-case (or screen) has the information necessary to help us build a model: a model composed of view objects and some sort of repositories (Sergio’s Builder?).
In several projects I was involved in it always surprised me how little one screen reuses view object code from the next (or most code except for UI components). It was like each developer coding a screen was living in complete isolation from the rest of the team. Perhaps giving the problem a more DDD approach we could start having a more supple design to this specific problem. At this stage, the use of a Builder pattern (or other pattern for that matter) could start to arise as deeper insight into our model.
Summing things up, I don’t think we will ever reach a consensus on what is the “best way” of solving this issue. Some UI domain will be better solved with a particular model subset, while other will not. Sergio’s solution is an already digested solution to his domain but it isn’t fitting Jesse’s needs any more than a generic Cargo Shipping model (like the one in the book) would fit a real cargo company software. Nevertheless I will keep Sergio’s proposal (as well as others) as Patterns and/or starting points to address my future UI domain modeling.