What Is Domain Driven Design Trying to Solve [DDD]

What does Eric Evans say about the definition of Domain Driven Design In the article, I quoted Eric Evans' definition of Domain Driven and translated it into Japanese as follows.

Focus on the core complexity and opportunities of your domain
Explore models in collaboration with domain and software experts
Write software that explicitly represents those models
Speak in a ubiquitous language in a bounded context

In this, the important points were not specified.

*** Why do we need to do something like the four in the definition? *** about it.

So what exactly is *** Domain Driven Design trying to solve? *** ***

What Is Domain Driven Design Trying to Solve?

DDD is one of the software development methods. So first, let's think about the purpose of software development.

Why do people develop software? It can be said that *** is to solve some problem of the target of softwareization.

This "target to be converted into software" is called a "domain". Software originates from a particular domain and is deeply involved in that domain.

So what is DDD's approach to software development? See also What does Eric Evans say about the definition of Domain Driven Design [DDD Reference](http: / At the beginning of /domainlanguage.com/ddd/reference/), there is a description like this.

Many projects do modeling work without getting much real benefit in the end. The patterns of DDD distill successful practices from projects where dramatic benefits have come from modeling.
Many projects end up without significant profits from *** modeling. *** DDD extracts successful patterns from projects that have made dramatic profits *** from *** modeling.

That is, DDD is

*** Increase the value of software *** by domain modeling

We are taking the approach.

So what does it mean to benefit from modeling?

What does "profit from modeling" mean?

First, let's check the definition of the model. By Eric Evans' definition, it is *** "an abstraction of a particular aspect of things to solve a problem" ***. The real world cannot be turned into software as it is. It needs to be abstracted in a way that is suitable for problem solving, and the product is a model.

Let's consider a concrete example.

Example: Daily report modeling

For example, I have a business to write a daily report on paper. "I don't have a place to physically put the daily report, so I want to complete it online." Let's assume that it is systematized to solve the problem.

There is a great deal of information in the real world.

The name of the person who wrote the daily report, the date and content of the daily report,
Number of pages, price, material, purchaser, of booklet to write daily report
The place to close the daily report, the pen to write the daily report, the place, the time ...

There is infinite information depending on how you cut it out.

As mentioned above, it is impossible and not necessary to put all of this into software.

Therefore, in this software, we have defined as follows as the information necessary to solve the above problem.

The name of the person who wrote the daily report, the date and content of the daily report

This is the model.

What is a good model

So what is a good model? Given the definition of "an abstraction of a particular aspect of things to solve a problem," a good model can solve that *** problem, and a bad model that can't.

So what is the model that cannot solve the problem? Consider the example of a daily report.

When analyzing the daily report business (hereinafter, domain), Actually, the daily report is used for exchanging feedback comments from my superior, and I found that this cannot be eliminated without this systematization.

However, the current daily report model only has the information "the person who writes the daily report, the date and content of the daily report". This cannot express the concept of feedback and cannot solve the problem of "I want to complete the daily report online" that exists in the domain.

In other words, the previous model is inadequate and a bad model.

So how do you make a good model and profit from modeling?

Approach to profit from modeling

As you can see from the daily report case, in order to solve the problem, it is necessary to understand the domain correctly and reflect it in the model. Furthermore, in order to add value as software, it is necessary to reflect it from the model to the software.

Therefore, DDD roughly divides into the two approaches shown in the figure below.

1. Deepen your understanding of domains and continue to improve your model

In the example above, we found that without an understanding of the domain, the problem could not be solved correctly. So how do you understand the domain?

Yes, you have to ask someone who is familiar with the *** domain ***.

How often do you listen?

Should I model and release the software before getting feedback? It's not hard to imagine that it's better to match the perceptions at the stage of creating the *** model. Once you've created and updated your model, it's better to reconcile your perceptions each time, and you'll have less rework and a better chance of improving your model early.

In other words, to deepen your understanding of the domain, *** It's important to get feedback on your model as often as possible from someone familiar with your domain ***.

Defined approach

DDD names and defines this approach.

People who are familiar with domains are called *** "domain experts" ***, and in principle, we use the same words as domain experts and "explore" models together.

At this time, in order to prevent recognition discrepancies and reduce the cost of converting different words, it is also a principle that all domain experts and developers "use the same words", and that word is *** "ubiquitous language". We call it ***.

Also, since it is not realistic to say "a model common to the whole world" and "a model common to the entire company", it is a boundary to clarify it from the idea of deciding the scope of application of this model. The attached context is "***".

Please refer to this article for a detailed explanation of this area. Bounded Context Concepts Bounded Context Implementation

2. Continuously reflect the model in the software

As the model continues to improve, it naturally becomes necessary for the software to reflect the changes. Being able to handle this is a big requirement for *** software ***!

Since the normal model is close to the DB, it is easy to avoid changes as much as possible in consideration of cost. Without solid preparation at the architectural level, it will be difficult to meet this demand.

On the other hand, in DDD

Write software that expresses the model as it is
Use proven DDD design patterns

We advocate the approach.

Write software that represents a model

So that the model-software mapping is clear *** We aim to express the model on software as much as possible ***. Please refer to the article What is expressing domain knowledge in a model for a concrete example. Please give me.

This is for practical reasons.

The more complex the model, the harder it is to understand its mapping and the more difficult it is to reflect frequent changes. Also, even if you try to describe the model information in the document, the document is often out of date, and it is highly likely that the knowledge of the model will not be reflected or it will be transmitted in the wrong state.

"Ubiquitous" in the concept of ubiquitous language mentioned above means "In everywhere", which means "***" in the domain expert's remarks, developer's remarks, and *** "software. ..

Use proven DDD design patterns

This is exactly what is known as the so-called "tactical DDD". To withstand frequent code modifications, it requires a fairly high level of maintainability. To that end, entities and repositories are defined as *** highly cohesive design patterns *** derived through various projects.

Generally recognized (and likely) as a benefit of DDD, *** "Writing code that is easy to maintain" wasn't really the primary purpose ***. The correct position is that patterns such as famous entities were by-products created to achieve their goals.

As an aside, the pattern that introduces only tactical DDD is sometimes called "lightweight DDD". I personally think that it makes sense if you think of it as "incorporating only a good design that can withstand frequent model changes." However, there is a model at the base of thought, so if you think about it without it, I think that wrinkles will go somewhere.

Summary

Why do you do DDD in the first place? I think there weren't many opportunities to delve into that. By understanding this first, I think that you will be able to work with intentions rather than just tracing the approach defined by DDD.

If you want to know more

We have published a book for those who are learning DDD for the first time, or for those who have actually started and are facing difficulties.

Domain Driven Design Modeling / Implementation Guide

Starting with an explanation of the "purpose of DDD" and "model" that tend to get lost, We aim to experience the appeal and effects of DDD based on examples of concrete modeling and implementation.

The "Chapter 1 DDD Overview" section of this book provides a more detailed explanation of this article. Please purchase if you like.

Twitter also accepts questions about DDD and through a service called "Question Box". Please follow me if you like.

@little_hand_s