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

• Invest our efforts in what matters most to the business.

• Focus on what distinguishes our business from all the others.

• Deliver exactly what is needed to achieve a competitive advantage.

• Focus on the Core Domain.

A Refined, Precise Definition & Understanding of the Business is Developed

• 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.

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.

Clean Boundaries Are Placed Around Pure Models

• 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.

Enterprise Architecture Is Better Organized

• 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.

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.

New Tools, Both Strategic & Tactical, Are Employed

• 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.