More on this book
Community
Kindle Notes & Highlights
DDD isn’t first and foremost about technology. In its most central principles, DDD is about discussion, listening, understanding, discovery, and business value, all in an effort to centralize knowledge. If you are capable of understanding the business in which your company works, you can at a minimum participate in the software model discovery process to produce a Ubiquitous Language.
Using DDD, you never try to model the whole business enterprise with a single, large domain model.
DDD brings domain experts and software developers together in order to develop software that reflects the mental model of the business experts.
The Ubiquitous Language is a shared language developed by the team—a team composed of both domain experts and software developers.
Draw pictures of the physical and conceptual domain and label them with names and actions.
Create a glossary of terms with simple definitions. List alternative terms, including the ones that show promise and the ones that didn’t work, and why.
Bounded Contexts are relatively small, smaller than we might at first imagine. A Bounded Context is large enough only to capture the complete Ubiquitous Language of the isolated business domain, and no larger.
If you try to apply a single Ubiquitous Language to an entire enterprise, or worse, universally among many enterprises, you will fail.
A Core Domain is a part of the business Domain that is of primary importance to the success of the organization.
I have something more to tell you about domains. They have both a problem space and a solution space. The problem space enables us to think of a strategic business challenge to be solved, while the solution space focuses on how we will implement the software to solve the problem of the business challenge.
It is a desirable goal to align Subdomains one-to-one with Bounded Contexts.
Another trap would be to divide Bounded Contexts in order to distribute tasks to available developer resources. Technical leads and project managers might think it is easier for developers to manage smaller tasks. While that might be the case, enforcing boundaries for the sake of task distribution plays false to the linguistic motivations of contextual modeling. In fact, there is no need to impose fake boundaries in order to manage technical resources.
This nuance serves as another visual cue. Upstream models have influences on downstream models, as activities on a river that occur upstream tend to have impacts on populations downstream, whether positive or negative. Consider pollutants dumped into a river by a large city. Those pollutants may have little impact on that city, but downstream cities may face severe consequences.
