Considering favoring composition over inheritance and looking at various design patterns there are multiple approaches to modeling a domain.

Say you have some Entities which are very similar in some respects, yet differ widely when it comes to technical implementations. To try portray the scenario here is the classic car example.


From a user perspective, they are all pretty much the same (all vehicles). From a DDD perspective, car, truck, van all share certain common state (number of tires, engine, ...) and certain behaviors (steering, changing speed, ...). However, they also have various state and behavior that is unique such as the Truck's bed, the van's internal storage, or the cars 5 seats. As time progresses there will be a fair amount of change. Validation would be different for certain things, and similar for others. Change speed, steer, etc. are similar, yet pull trailer is optional and even that differs between e.g. the Van and Truck.

How would you design this to cope with change, yet remain DRY and adhering to the DDD mindset? Please explain how you would go about it (pseudo code?) and mention any design patterns or strategies you would try implement to model this (simple, yet dynamic) domain and which OO principles are being applied etc.


Looks like the purpose of the model is missing from the picture. DDD is not about modelling reality: it's about discovering the model which is the best fit for the specific purpose. Design patterns will eventually follow.

| improve this answer | |
  • :) Excellent, I wanted but can't give you more than 1 up, sorry about that – InformedA Jun 17 '14 at 9:15
  • btw, I read what DDD is about. Still have no clue what it is. But what you said applies for software design, not just this or that methodology. – InformedA Jun 17 '14 at 10:41
  • I may expand my words a little. – ZioBrando Jun 17 '14 at 10:45
  • 1
    No no, your wording is fine. I just don't understand the things they write to define and describe DDD. – InformedA Jun 17 '14 at 10:48
  • I may expand my words a little. After 10 years the Blue Book now looks misleading to me. The elegance of the design that it apparently advocates is in fact just a necessary condition of a continuous learning path that leads to frequent rewriting. One can't continuously evolving a codebase efficiently if the design is missing. However not all codebases need to be continuously evolved. This happens only in very complex areas (we need to change code as long as we learn) or in areas with highly evolutionary forces (i.e. business or market pressure). – ZioBrando Jun 17 '14 at 10:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.