New York September Class Sold Out!
- Book early for the March 2011 class
$2790$2090 if booked by Jan 14
Course descriptions, registration and more dates here »
Or call us at: (+1) (914) 861-5264
Will DDD work for your team?
Four Prerequisites for Domain-Driven Design
by Eric Evans
While the Strategic Design techniques of DDD can be applied in many situations, development based on subtle domain models has some demanding prerequisites. If you don't have them, it is a waste of effort to leap into application of DDD at the tactical level.
Instead of grinding your gears trying to express elegant models, you'd do better to direct your efforts toward establishing these conditions for success.
This is real life, and nothing is perfect. However, you really must have some form of the following,
Access to domain experts
DDD is a creative collaboration between software practitioners and business practitioners. This does not imply a full-time commitment. In fact, a true full-time commitment would actually contradict our definition of a domain expert, a practitioner with deep understanding of the business. Fine distinctions are important here. I'll define three of the various roles non-technical people play on a software project: user, customer, and domain expert.
A user is a person who will actually use your software when it is delivered. This role is vital for usability and for certain kinds of requirements gathering. However, this person may or may not be a domain expert. A user may be a clerical or blue-collar worker who takes care of a narrow, well-defined job, yet has no deep understanding of the business they are working in.
A customer/product owner is person who has authority to make decisions about scope and priorties of development -- a central role in an Agile process, and often filled by a person who is also a domain expert. However, this person might be a manager who is not close enough to the specialty being addressed in the project. Also, relying exclusively on the product owner is an unnecessary limitation, best avoided given what a constraint access to domain expertise is for most projects.
A domain expert is a person who has deep knowledge of the domain. Notice that this person does not need authority to make decisions. This person may or may not use the software. However, this person must be a practitioner. That is to say, the domain expert's primary job responsibilities involve solving problems in the business area being addressed, not in supporting software development.
Because you are not a domain expert, it may be difficult to know if someone is truly expert. Time will tell. A domain expert should be able to answer questions not only of 'what' and 'how' (that is, what should the software do and how should it do it) but also 'why'. Asking why things work the way they do, in both the software and the business, is a key to success in domain modeling (often neglected). It also helps you find the limits of your business counterpart's knowledge. A true domain expert can tell you the reasons the business is set up the way it is, and the reason behind those reasons.
No one is an expert on everything. You may well need more than one domain expert to cover the full scope of the project. Also, experts do not always see eye-to-eye on every point. As you dig deeper, you'll find that many apparent disagreements are actually the result of domain experts answering context-specific questions. Then again, sometimes they just disagree. All part of the fun of domain modeling! Remember, when this happens, that major project risks are being exposed and dealt with that would have been invisible without adequate involvement of domain experts.
Beware the pitfall of the "proxy domain expert". This is usually an analyst who has worked in the business so long that they know a lot about it. They might even have been a practitioner long ago. Although analysts can be valuable to a DDD team, they are not a substitute for a domain expert.
A variation on proxy domain expert is the analyst as single point of contact with the business. In this set up, analyts talk to the domain experts and relate a predigested distillation of what they have learned back to the team. This defeats the creative collaboration.
You must have true domain experts directly involved in the project to do DDD.
Iterative Process
A software development team learns a tremendous amount about the domain in the course of a productive software project. Domain modeling is a process of distilling knowledge. The beginning of a project is the moment when a team has the least knowlege of the domain they will ever have. This is the moment when they invent the most naive models they will ever invent. Upfront modeling locks in the team's initial ignorance.
This is why the Waterfall methods do not lead to practical or insightful domain models. This is why Agile processes are a good fit for DDD projects. However, be aware of the distinction between iterative and incremental.
Incremental development is the gradual addition of new features and capabilities to your software, and it is vital to successful development, avoiding the various failures of "big bang" approach.
Iterative development means that you redo things that already work. This can take the form of refactoring, when we want to change the design while keeping the behavior the same. It can be broader, when we decide to take a whole different approach to the problem we are solving. In DDD, it takes the form of changing the way we think about the problem and then changing the design to follow that new concept.
All too often, projects are described as having an iterative process when actually they have only incremental.
You must rewrite working software in order to do DDD.
Clean, Bounded Context
The topic of context mapping is too involved to fully explain here. It is introduced in this presentation on strategic design, and it is discussed in depth in chapter 14 of my book.
In brief, a bounded context defines some part of the software where a particular model applies. There are always multiple models in play on a software project. Trying to bring about a single unified model (aka an Enterprise Model) is a common strategic mistake. Bounded contexts allow multiple models to coexist without confusion and corruption. In practical terms, a context boundary is typically a subsystem boundary or a well-defined part of a subsystem. These boundaries emerge and are maintained on some projects and not on others.
Bounded contexts come in different flavors. Some are disciplined and orderly while some are chaotic. The subtleties of sophisticated modeling approaches don't survive the chaos of a project without boundaries, where different conceptual models mix in a big ball of mud, or a context where frequent sloppy design choices undermine fine distinctions and careful decoupling. At best, in such a context, domain objects become anemic wrappers of database records.
Fortunately, disciplined development can coexist with such uncontrolled hacking when it is within a bounded context with good isolation. (The isolation techniques are discussed in the previously mentioned chapter and other places, such as this case study.) A context where we do DDD needs to have these characteristics:
Not all of your system will be tidy and controlled, nor does it need to be. It is best to focus DDD on specific areas of high value and complexity. Unfortunately, it is also common to encounter an organization that lacks the discipline to establish any clean bounded contexts at all. In such a situation, DDD will not work.
The strategic design technique of context-mapping helps you to see what is going on and what factors might be preventing the formation of bounded contexts. This view can help a team to plot a realistic path to a more desirable configuration. It may also allow the team to recognize that it is not a realistic goal.
Skills on the Team
This is the hardest to define. Obviously, a team needs a level of skill; and equally obviously most projects will not be fully staffed with experienced DDD experts.
DDD is challenging in part because it demands skills in multiple areas - especially the combination of an ability to think rigorously and abstractly with an ability to effectively interact with non-technical domain experts plus some hands-on understanding of the implementation environment. Not every organization can muster such a team.
Nonetheless, everyone has to start somewhere, and one or two members of the team who have these kinds of skills together with others who are willing to follow their lead and eager to learn, can accomplish a lot and potentially progress rapidly. All members of the team need the shared vocabulary of the DDD patterns and a commitment to finding the pragmatic balance between clean models and keeping the forward momentum.
I wrote my book, Domain-Driven Design, in part to help people climb this learning curve and shift their mind-set. The training classes from Domain Language, and in particular the DDD Immersion, can really help someone make the leap from object-oriented programmer to domain-driven designer. When taken as an in-house class for a team, it can help align them and jump-start a project.
Take the first step
Looking at these four conditions, it is easy to be paralyzed. Some are difficult indeed, and you need all of them.
Don't dispair. If you lack one or more of these prerequisites, then redirect the energy you might have wasted on fruitless model refinement and instead focus it on establishing the necessary conditions, at least within a limited context. Seek out a domain expert and forge a relationship. Train up the team. Make rules about who can modify your team's code. Identify the particular gaps you have and fill them. Conditions will never be perfect. You need to have each of the four in a basic form. Meanwhile, the actions you take to establish these conditions provide benefits along the way.
Then, when you finally apply DDD in a context with all four prerequisites in place, you will feel the difference immediately. You will stand to realize the potential of domain modeling.
Coming Next Month: How do you get started with DDD when you are tied to a legacy 'big ball of mud'?
Eric Evans writes in our January newsletter about pragmatic techniques with.