8. Domain-Driven Design – Conclusion
Summary
- Use Domain-Driven Design to collaborate among all project disciplines and clearly understand the business requirements.
- Establish a Ubiquitous Language to discuss domain related concepts.
- Use Bounded Contexts to break down complex domains into manageable parts.
- Use Command-Query Separation to simplify your designs and improve performance.
- Implement a Layered Architecture to focus on different aspects of the application.
Questions, Feedback, and Sharing This Article
Now that you've gone through all 8 sections of this Domain-Driven Design article, please:
- Send me your questions and feedback on Twitter
- Recommend this article (link to the beginning) to your friends and colleagues wherever you hang out these days – Twitter, LinkedIn, Threads, Slack, Teams, Discord, etc.
In my opinion, there's nothing more fun than hosting a domain modeling party :)
Further Reading
- Eric Evans, Domain-Driven Design – The original work describing a vision and approach for dealing with highly complex domains.
- Vaughn Vernon, Implementing Domain-Driven Design – A detailed look at implementing systems using DDD - highly recommended.
- Abel Avram & Floyd Marinescu, Domain-Driven Design Quickly - an online book introducing the fundamentals of DDD.
- Bertrand Meyer, Command-Query Separation - an approach to simplify designs and improve performance by separating reads from writes
- Greg Young, Unshackle Your Domain – An excellent presentation describing the benefits of separating commands from queries and event driven design
- Greg Young, Command-Query Responsibility Segregation – this approach takes CQS a step further by creating two separate end-points for reads and writes
- Udi Dahan, Clarified CQRS – another nice article clarifying the CQRS pattern
- Martin Fowler, Anemic Domain Model – good argument against objects without behavior