What is Domain-Driven Design?last revised August 16th, 2017 originally published July 20th, 2014
Domain-Driven Design, or DDD, is an envelope that encapsulates software design theory and technique as well as theory and technique for communication. The focus of the DDD brand is to increase developers’ capability to manage complexity in software design.
Some of the targeted complexity is tactical in nature (technical code bits) and some of the targeted complexity is strategic in nature (planning, communication).
A community of developers (and others) has formed around DDD. Therefore, it’s to be understood that this community is made up of individuals who join a social context in order to network and collaborate with people and ideas related to managing complexity in software design.
The DDD community is diverse and accepting. On average, DDD communicators are experienced developers, often with team leadership experience. The community is widely respected due to shared interest in understanding engineering trade-offs and seeking to discover consistently more effective models.
Below begins the original article.
Domain-Driven Design (or DDD) is a software development approach that focuses on the domain model first. Techniques within DDD allow teams to separate various “domains" (related parts of the application) from one another with the resulting benefit of trading away generic models that hold the behavior for many contexts with models designed to a specific context.
DDD is linguistic, analytic, and strategic. It encompasses many areas of software design including interacting with clients and implementing design-patterns.
At Laracon NYC, I gave a talk on command oriented interfaces and domain-events. These patterns are often utilized with DDD but are themselves not a core concept of DDD at all.
As I mentioned during the talk, the talk was not about DDD. But rather, was inspired by the rich service layer movement that seems to be flowing from DDD through our community.
I have begun to create a video series to go over many tactical components of domain-driven design at http://eventsourcery.com The series focuses on programming techniques including CQRS and Event Sourcing.
I believe that many developers (like me) started to get a taste of the benefits that DDD has to offer and decided that they wanted more.
But, what is DDD exactly?
At first, DDD seems like a nebulous concept full of other nebulous concepts. However, during my pursuits I’ve started to nail down specific resources that I believe can give clarity to these ideas.
Vaughn Vernon (the author of the red book –more info later–) gave two presentations at TechEd North America 2014 that are startlingly good introductions to DDD. The first covers the core concepts of DDD including the ubiquitous language, domains, bounded contexts, context mapping, and aggregation.
Vaughn’s second session covers implementing aggregates and entities effectively. He utilizes .NET however the concepts hold true, so PHP developers don’t be scared away.
So far, these are the best introductions to DDD that I have found. Once you have consumed these videos, you may have a desire to dig further. If you’re like me, you’re very interested in these strategies for understanding and developing enterprise applications.
When you’re ready, it’s probably time to grab the blue and red books.
The book Domain-Driven Design by Eric Evans is considered to be the seminal work. It’s heavy on concepts and light on implementation. We’re software engineers. We focus on code and design-patterns on a regular basis. It is my belief that while we study more design-patterns, techniques, and tools, we have not been growing as steadily in terms of strategic domain modeling. There is more than one side to the development coin and DDD is helping me to see how I can grow in ways separate from the object-oriented paradigm.
Implementing Domain-Driven Design by Vaughn Vernon (yes, the speaker mentioned earlier in this post) is an evolution of Eric Evan’s book in that it provides additional explanations and ideas. However, it focuses much more heavily on implementation than the blue book. Implementing Domain-Driven Design discusses ideas about handling access control, implementing context maps, and many other code-focused topics. It is my personal opinion that this book is best digested after reading Evans’ blue book.
Between these works, we have enough to begin mastering DDD.
Aside from the books, we have a number of online resources to assist us. This list will be updated as I find more material.
- DDD Quickly is a free short ebook that covers many of the ideas behind DDD and can serve as a good start. Of course, it can’t compete with the blue or red books.
- The DDD in PHP user group is a great place to ask questions and get answers. It may be worth your while to simply invest in reading the discussions a bit by bit each day until you’re caught up. In reality, the total time spent doing such is a drop in the bucket for the amount of information available from this resource.
- Ross Tuck also discusses some topics on his blog. Again, do not skip over the comments as within exists quality information.
- How You Can Architect and Develop Enterprise Mission-Critical Applications with Domain-Driven Design
- How You Can Implement Aggregates and Domain Entities Effectively in Domain Models, with .NET
- Implementing Domain-Driven Design Video Book Club Jeff Carouth is leading a video book club for the red book. If you’re reading the red book, you might watch the video for the chapter you just finished. This can help you further cement the ideas that you covered over that chapter.
And last but not least… The PHP Friends of DDD have compiled a massive “State of the Union" index of resources.
- Do Androids Dream of Microsoft Excel?
- Practical Techniques to Reduce the Harm of Active Record
- Aggregates for Those Familiar with ActiveRecord
- Simplifying Test Development
- Active Record: How We Got Persistence Perfectly Wrong
- Testing is Part of the Production System
- Card-based Simulation Engine
- Test Code is Application Code
- Testing at Boundaries with Test Doubles and Fixtures
- Adding Real Capabilities to Systems Through Naming
- Some Game Projects
- Avoiding Unified Data Models Talk
- More Relaxed Typing with Dvorak
- Event Sourcery
- What is Domain Modeling
- What is Active Record
- A Talk About Naming Things Talk
- Designing A Model Architecture Talk
- Dev Discussions Podcast
- What is a Repository
- Command Bus
- What is Domain-Driven Design?