What Is Domain-Driven Design?

Chapter 10. Getting Started with Domain-Driven Design

This report has introduced domain-driven design’s tools for analyzing business domains, sharing knowledge, and making strategic and tactical design decisions. At first, it might seem overwhelming to come to grips with all these concepts, let alone to implement them in practice. The good thing is that it’s not all or nothing—you don’t have to apply all of DDD’s patterns and practices to gain value from it. This is especially true for brownfield projects, where it’s practically impossible to introduce all the patterns and practices in a reasonable time frame.

In this final chapter, we will look at a number of tips and tricks for gradually incorporating domain-driven design into your projects.

Ubiquitous Language

The use of a ubiquitous language is the cornerstone practice of domain-driven design. It is essential for domain knowledge discovery and sharing, and for effective solution modeling.

Luckily, you don’t need a corporate strategy to use a ubiquitous language. This practice is so trivial, it’s borderline common sense. Therefore, appeal to common sense. Listen carefully to the language used by the stakeholders when they speak about the business domain. Gently steer the terminology away from technical jargon toward its business meaning.

Look for inconsistent terms, and ask for clarifications. For example, if there are multiple names for the same thing, look for the reason. Are those different models intertwined in the same ...