DDD: Chapters 7-9

Chapter 7 is another reason of why I love this book; the concepts are well explained and the illustrations are very easy to understand through the use of scenarios and diagrams. The ability to nail down the objects within a software model is a key responsibility for all architects, so being able to establish an approach, such as discussed in this book, adds to my skill set. I love reading this book because it talks about concepts that I already know, but adds a new spin on it allows me to make key decisions when things are not too clear--such us with entity vs. value objects, aggregate boundaries, integrating with legacy systems etc.

Chapter 8 expounds on the idea of refactoring and how it should be done in stages before finally arriving at a breakthrough discovery that can greatly improve the model. Refactoring is essentially like a puzzle; it starts off with little hints that gradually improve the model and then once there is a cleaner picture, provides a smoother and easier transition to the end when a complete picture is attained. I am not saying a real life software domain model will ever become a complete/perfect model (there will always be ways of refining it) but you get the point.

Chapter 9 introduces the specification as a way of introducting contraints as part of the domain model. Specification objects are introduced as possible solutions to validation, selection and generation of objects keeping the contraints in mind. It is interesting how domain-driven design is willing to comprise on decoupling the repository from the domain to improve performance by allowing the use of SQL as substitutes to holding objects in memory for purposes of querying. I don't know if I fancy the approach of trying to link the specification to the repository using double-dispatch, but I guess it is probably the cleanest way of mingling sql with domain objects. I guess this is where frameworks like hibernate make life easy for a developer.