Make domain-driven design a part of your professional toolbox, not an organiza‐ tional strategy. DDD’s patterns and practices are engineering techniques, and since software engineering is your job, use them!

Let’s see how to incorporate DDD into your day-to-day job without making much ado about it.

Ubiquitous language

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

Luckily, this practice is so trivial that it’s borderline common sense. Listen carefully to the language the stakeholders use when they speak about the business domain. Gen‐ tly steer the terminology away from technical jargon and toward its business meaning.

Look for inconsistent terms and ask for clarifications. For example, if there are multi‐ ple names for the same thing, look for the reason. Are those different models inter‐ twined in the same solution? Look for contexts and make them explicit. If the meaning is the same, follow common sense and ask for one term to be used.

Also, communicate with domain experts as much as possible. These efforts shouldn’t necessarily require formal meetings. Watercoolers and coffee breaks are great com‐ munication facilitators. Speak with the domain experts about the business domain. Try using their language. Look for difficulties in understanding and ask for clarifica‐ tions. Don’t worry—domain experts are usually happy to collaborate with engineers who are sincerely interested in learning about the problem domain!

Most importantly, use the ubiquitous language in your code and all project-related communication. Be patient. Changing the terminology that has been used in an orga‐ nization for a while will take time, but eventually, it will catch on.

Bounded contexts

When exploring possible decomposition options, resolve to the principles behind what the bounded context pattern is based on:

• Why is it better to design problem-oriented models instead of a single model for all use cases? Because “all-in-one” solutions are rarely effective for anything.

• Why can’t a bounded context host conflicting models? Because of the increased cognitive load and solution complexity.

• Why is it a bad idea for multiple teams to work on the same codebase? Because of friction and hindered collaboration between the teams.

Use the same reasoning for bounded context integration patterns: make sure you understand the problem each pattern is supposed to solve.

Tactical design decisions

When discussing tactical design patterns, don’t appeal to authority: “Let’s use an aggregate here because the DDD book says so!” Instead, appeal to logic. For example:

• Why are explicit transactional boundaries important? To protect the consistency of the data.

• Why can’t a database transaction modify more than one instance of an aggregate? To ensure that the consistency boundaries are correct.

• Why can’t an aggregate’s state be modified directly by an external component? To ensure that all the related business logic is colocated and not duplicated.

• Why can’t we offload some of the aggregate’s functionality to a stored procedure? To make sure that no logic is duplicated. Duplicated logic, especially in logically

and physically distant components of a system, tends to go out of sync and lead to data corruption.

• Why should we strive for small aggregate boundaries? Because wide transactional scope will both increase the complexity of the aggregate and negatively impact the performance.

• Why, instead of event sourcing, can’t we just write events to a logfile? Because there are no long-term data consistency guarantees.

Speaking of event sourcing, when the solution calls for an event-sourced domain model, implementation of this pattern might be hard to sell. Let’s take a look at a Jedi mind trick that can help with this.

Event-sourced domain model

Despite its many advantages, event sourcing sounds too radical for many people. As with everything we’ve discussed in this book, the solution is to let the business domain drive this decision.

Talk to domain experts. Show them the state- and event-based models. Explain the differences and the advantages offered by event sourcing, especially with regard to the dimension of time. More often than not, they will be ecstatic with the level of insight it provides and will advocate event sourcing themselves.

And while interacting with the domain experts, don’t forget to work on the ubiqui‐ tous language!