DDD Concepts and Patterns – Final

We now arrived at the last post of this series about Domain-Driven Design (DDD) patterns and practices. It is about the combination of the different strategic design practices and how to start the application of them.

The three strategic design practices context, distillation, and large scale structure don’t stand in isolation. We need to combine them to leverage their full potential. Eric Evans provided some guidance on where to start in his original book about DDD [Eva04].

Example of combinations

We can apply the large-scale-structure of responsibility layers on multiple levels of scale. Many examples focus on the layers within a bounded context. But as the system grows, we may want to apply such a structure on the level of different bounded contexts.

Also, the large-scale-structure itself could be an integral part of the core domain. When the structure resembles and focuses part of the business domain, it becomes part of it.

Distillation of the core domain always leads to one or more bounded contexts, as we already learned in previous posts. With a context map that clearly shows the responsibilities and dependencies of the bounded context, developers get a structured guide of the system.

Assessment First

The following list of steps is copied one-to-one from Eric Evans’s book. You don’t need to follow it by word to be successful with strategic design, but I think it is a good start.

1. Draw a context map. Can you draw a consistent one, or are there ambiguous situations?
2. Attend to the use of language on the project. Is there a Ubiquitous Language? Is it rich enough to help development?
3. Understand what is important. Is the core domain identified? Is there a domain vision statement? Can you write one?
4. Does the technology of the project work for or against a model-driven design?
5. Do the developers on the team have the necessary technical skills?
6. Are the developers knowledgable about the domain? Are they interested in the domain?

Essentials for strategic decision making

When we make strategic design decisions, we need to ensure that it has a meaningful impact. Sometimes people in leading roles decide something but do not ensure that the decision is based on reality and gets known by the whole team (ivory tower architecture).

The following list of pieces of advice should help us implement strategic decisions.

1. Decisions must reach the entire team. Otherwise, people that don’t know will undermine it.
2. The decision process must absorb feedback. Imposing decisions on teams without considering feedback cannot be successful.
3. The plan must allow for evolution. Embrace an agile mindset regarding your decisions and validate them regularly.
4. Architecture teams must not siphon off all the best and brightest
5. Strategic design requires minimalism and humility. Less seems to be more regarding design decisions.
6. Objects are specialists; developers are generalists. Most developers are keen to not only write code but also influence the design.

Wrap Up / Final Thoughts

DDD touches many areas of software development. Not only the code and design are part of it but also the development process as a whole. We don’t have to agree with everything in DDD. But generally, I think it points in the right direction when we want to standardize and professionalize our still very young craft.

[Eva04] Eric Evans: Domain-Driven Design – Tackling Complexity in the Heart of Software (homepage)