The Business Value of DDD

We must justify everything that we do

Developers can no longer pursue technologies and techniques just because they sound cool.
The best justification for any tech decision is to provide value to the business.

The Organization Gains a Useful Model of its Domain

The business may come to understand itself & mission better than before.
The Ubiquitous Language should be incorporated into vision docs & mission statements.
These details can help your business analyze the value of the current & future direction, both strategic & tactical.

There's business value when the org grows a deeper understanding of the core business
When brought together to a DDD effort, domain experts gain consensus among themselves. This fortifies the effort and the organization as a whole.
Developers & Domain experts share a common language as a unified team.
Training & handoffs are easier. Reduced likelihood of developing tribal knowledge.

Often the End User Experience can be tuned to better reflect the model of the Domain.
Software that leaves too much understanding to its users (e.g. a CRUD interface), users must be trained to make a great number of decisions.
When user experience is designed to follow the contours of the underlying model, users are led to correct conclusions.
Less training. The software actually trains the user.

Alignment with Business advantage. Technical Team is discouraged from doing what might appeal more to their programming and algorithmic interests.
Effort is directed to where it matters most; understanding the Bounded Context of the project.

When Bounded Contexts are well understood & carefully partitioned, Teams understand where & why integrations are necessary.
Boundaries and relationships are explicit.
This can lead to a very through understanding of the entire enterprise architecture.

DDD is NOT a heavyweight, high-ceremony design & development process.
It's about carefully refining the mental model of domain experts into a useful model for the business.
The team's efforts should be iterative & incremental.
Any Agile process the team has chosen can be used.
The model produces is the working software.
It is refined continuously until it is no longer needed by the Business.

A Bounded Context gives the Team a modeling boundary in which to create a solution.
The Bounded Context contains a single, ubiquitous language.
Within the boundary, Teams may employ any number of tactical modeling tools: Aggerates, Entities, Value Objects, Services, Domain Events, and more.

Last updated 1 year ago

Domain Experts Contribute to Software Design

There's business value when the org grows a deeper understanding of the core business

When brought together to a DDD effort, domain experts gain consensus among themselves. This fortifies the effort and the organization as a whole.

Developers & Domain experts share a common language as a unified team.

Training & handoffs are easier. Reduced likelihood of developing tribal knowledge.

A Better User Experience Is Gained

Often the End User Experience can be tuned to better reflect the model of the Domain.

Software that leaves too much understanding to its users (e.g. a CRUD interface), users must be trained to make a great number of decisions.

When user experience is designed to follow the contours of the underlying model, users are led to correct conclusions.

Less training. The software actually trains the user.

Agile, Iterative, Continuous Modeling is Used

DDD is NOT a heavyweight, high-ceremony design & development process.

It's about carefully refining the mental model of domain experts into a useful model for the business.

The team's efforts should be iterative & incremental.

Any Agile process the team has chosen can be used.

The model produces is the working software.

It is refined continuously until it is no longer needed by the Business.