- Can I DDD?
- Why You Should Do DDD
- How To Do DDD
- The Business Value of Using DDD
- The Challenges of Applying DDD
- Fiction, with Bucketfuls of Reality
- Wrap Up
From the Rough Cut
From the Rough Cut
From the Rough Cut
The Business Value of Using DDD
If your experience is anything like mine, software developers can no longer pursue technologies and techniques just because they sound cool or intriguing. We must justify everything that we do. I think that has not always been true, but it is a good thing it is now. I think the best justification for using any technology or technique is to provide value to the business. If we can establish real, tangible business value, why would the business ever refuse to use what we recommend?
The business case is strengthened especially if we can demonstrate that the business values are higher with our recommended approach than with other options.
Let's consider some of the very realistic business value of employing DDD. Be sure to share this openly with your management, domain experts, and technical team members. The value and benefits are summarized in Table 1.6. Let me elaborate. I start off with the less technical benefits.
Table 1.6 The value and benefits of using DDD.
|
DDD Value And Benefits (A.K.A. How To Sell Ddd To Your Management, Domain Experts, And Technical Team Members) |
|
|
1. |
Organization gains a useful model of its domain |
|
2. |
Develop a refined, precise definition and understanding of your business |
|
3. |
Domain experts contribute to software design |
|
4. |
Gain a better user experience |
|
5. |
Place clean boundaries around pure models |
|
6. |
Better organize elements of your enterprise architecture |
|
7. |
Use agile, iterative, continuous modeling |
|
8. |
Employ new tools, both strategic and tactical, to your code |
1. The Organization Gains a Useful Model of Its Domain
The emphasis of DDD is to invest our efforts in what matters most to the business. We don't over model. We focus on the Core Domain (2). Other models exist to support the Core Domain, and are important too. Yet the supporting models may not be given the priority and effort of the Core Domain.
When our focus is on what distinguishes our business from all others, our mission is well understood and we have the parameters we need to keep on track. We will deliver exactly what is needed to achieve competitive advantage.
2. A Refined, Precise Definition and Understanding Is Developed
The business may actually come to understand itself and its mission better than before. I have heard others state that the Ubiquitous Language developed for the business's Core Domain has found its way into marketing materials. Certainly it should be incorporated in vision documents and mission statements.
As the model is refined over time, the business develops a deep understanding that can serve as an analysis tool. Details surface out of the minds of your domain experts as you are challenged by one another and shaped by technical team partners. These details can help your business analyze the value of the current and future direction, both strategic and tactical.
3. Domain Experts Contribute to Software Design
There is business value when the organization grows a deeper understanding of the core business. Domain experts don't always agree on concepts and terminology. Sometimes the differences are fostered by different experiences from outside before joining the organization. Sometimes it happens from the divergent paths required by each expert within the same organization. Yet when bringing them together to a DDD effort, the domain experts gain consensus among themselves. This fortifies the effort and the organization as a whole.
Developers now share a common Language as a unified team along with domain experts. They are further benefited by the knowledge transfer from the domain experts they work with. As developers inevitably move on, either to a new Core Domain, or out of the organization, training and hand-off is easier. The chances of developing “tribal knowledge,” where only a select few understand the model, are reduced. The experts, remaining developers, and new ones, continue to share a common knowledge that is available to anyone in the organization that requires it. This advantage exists because there remains an express goal to adhere to the Language of the domain.
4. Better User Experience
Often times the end user experience can be tuned to better reflect the model of the domain. Domain-driven is formally “baked in,” influencing human use of the software.
When software leaves too much to the understanding of its users, users must be trained to make a great number of decisions. In essence the user is only transferring the understanding in their mind into data that they enter into forms. The data is then saved to a data store. If the user doesn't understand exactly what is needed, the results are incorrect. Often this leads to “guess work” with related lowered productivity until users can figure out the software.
When the user experience is designed to follow the contours of the underlying expert model, it will lead users to correct conclusions. The software actually trains the users, which reduces the training overhead to the business. Quicker to productivity with less training. That's business value.
We next move into more technically-driven benefits to the business...
5. Clean Boundaries Around Pure Models
The technical team is discouraged from doing what might appeal more to their programing and algorithmic interests by aligning expectations with business advantage. Purity in direction allows for focus on the potency of the solution, with efforts directed to where they matter the most. Achieving this is very closely connected to understanding the Bounded Context of the project.
6. Enterprise Architecture is Better Organized
When Bounded Contexts are well understood and carefully partitioned, all teams in the enterprise develop an acute understanding of where and why integrations are necessary. The boundaries are explicit and the relationships between them are as well. The teams that have models that intersect by usage dependency employ Context Maps to establish formal relationships and ways to integrate. This can actually leads to a very thorough understanding of the entire enterprise architecture.
7. Agile, Iterative, Continuous Modeling
The word “design” can evoke negative thoughts in the minds of business management. However, DDD is not a heavyweight, high ceremony design and development process. DDD is not about drawing diagrams. It is about carefully refining the mental model of domain experts into a useful model for the business. It is not about creating a real-world model, as in trying to mimic reality.
The team's efforts follow an agile approach, which is iterative and incremental. Any agile process that the team feels comfortable with can be used successfully in a DDD project. The model that is produced is the working software. It is refined continuously until it is no longer needed by the business.
8. Tools, Both Strategic and Tactical
A Bounded Context gives the team a modeling boundary in which to create a solution to a specific business problem domain. Inside a single Bounded Context is a Ubiquitous Language formulated by the team. It is spoken with one another and in the software model. Disparate teams, sometimes each responsible for a given Bounded Context, use Context Maps to strategically segregate Bounded Contexts and understand their integrations. Within a single modeling boundary the team may employ any number of useful tactical modeling tools: Aggregates (10), Entities (5), Value Objects (6), Services (7), Events (8), and others.