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.
2 comments:
Hi Roni,
it's good to read your thoughts about this problem.
I, as you, think that there is not a silver bullet for problems.
So, my Builder was not intended to be a general, always applicable, solution for constructing all types of view objects in every situation, even if I think it could fit many common needs.
There will always be some problem which will ask you for a new solution: so, I think the best approach is to develop own ideas about how to solve problems, read other ideas or solutions, and then use all this stuff for directly solving problems or as a starting point for new ideas and solutions.
All the best,
Sergio B.
What I wanted to start expressing as I thought about the discussion is that I need to exercise my thinking about this problem in new terms. I'm even reading again the book and taking particular notice on Strategic Design issues, like Bounded Context, Shared Kernel, because they can be related to the UI/Model problem, hence why you can have multiple solutions.
AS I continue reading and thinking about it I will keep posting (probably in the forum first)
Post a Comment