DDD: Chapters 4-6

I find it very interesting how several projects set off with the goal of generating a completely object-oriented model and basing the implementation solely on this model. We have already discussed how challenging it is to keep the code in sync with the conceptual model. Even more difficult, in my experience, is the challenge of keeping business logic out of the UI. Every modern developer knows the rule of keeping java code out of JSPs and yet in the crunch, usually when the PM is breathing down your neck, most developers take the easy way out by settling for "smart UI". Althought, a 100% separation of conceptual layers is probably impossible to attain; I am quite certain that the more separation there is the better. Especially since most frameworks of today provide the separation and allow for object plugins. Also key is the separation of infrastructure from the domain layer, allowing for easy replacement of third part components through the infrastructure layer.

Also discussed in this reading is the expression of the domain model in the form of diagrams, and also certain techniques that are used to improve the representation of objects in the model while keeping in mind the runtime effectiveness of the model. The reading also discusses the differences between entities and value objects, which along with service objects have become a common pattern used to represent models and their communications between layers. I was surprised that no mention of the use of hashCodes in java, especially EJB, was made in the chapter as a means of identifying entities--since most containers use the hashcode to identify entities that are pooled in an EJB container. Last to be discussed is concept of cohesion and coupling within modules, and why the object-oriented paradigm has become the popular choice to model domains.

Chapter 6 reveals very creative ways of representing a domain model, paying particular attention to separation of responsibilities and trying to simplify objects to allow for component replacements, reuse and scalability. Obviously, the concept of a factory in OO design is one that is frequently discussed in patterns such as factory and factory method. This chapter's strategy of creating repositories and trying to mix up the use of factories and repositories is creative and helps simplify the model. Ultimately these patterns discussed in chapter 6 lead us to understand the importance of separation and also how best to merge such concepts into frameworks and allow for plug-in development.