DDD serialized article
Why do DDD beginners get sick immediately after getting rid of it
What does Eric Evans say about the definition of Domain Driven Design
What is the expression of domain knowledge in a model
What is the most accessible architecture to get started with Domain Driven Design
Domain Driven + Onion Architecture Overview
We'll talk about how to think of a "model" in Domain Driven Design and the need for a bounded context.
"Bounded context" is a very important but difficult point to understand in Domain Driven Design, so I'll try to make it easier to understand its necessity and definition.
I often hear the words "model" and "modeling" in software development, but I think some people have never stopped and thought about the definition.
If you try to google the definition in Japanese, it seems that it is often talked about in the context of UML. Since it is an abstract word, I think there are various definitions, but I will quote the definition of the article of Nikkei Computer.
IT Report (Keyword 3-minute course) --Modeling
A system construction technique for visualizing invisible things such as business flow and system structure.
Create a plan view (model) using symbols.
The model is written as *** to visualize what is invisible.
I think this is also correct in some contexts, but when modeling domain-driven, it's sometimes better to be a little careful.
*** Modeling = Not a correct representation of what is in the real world ***
about it.
Take a look at Eric Evans' DDD Reference (http://domainlanguage.com/ddd/reference/).
(What is this material What does Eric Evans say about the definition of Domain Driven Design I wrote in the article)
model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain An abstraction used to represent a particular aspect of the area of interest and solve related problems
The important thing is that the
model represents *** selected aspects ***, and
the purpose is *** to solve the related problem ***. that is how it is.
Abstracting a specific event is premised on "it is impossible to describe it accurately" because it strips away various concrete things. So what are you aiming for without aiming for accuracy?
It is *** whether it meets the purpose of problem solving ***.
I think this is a little different in nuance from "visualizing".
As an example, in Domain Driven Design (en.wikipedia), there is such a description about the difference between Entity and Value Object. (I will write an article about the definition of Entity and ValueObject later)
Example:
Most airlines distinguish each seat uniquely on every flight. Each seat is an entity in this context.
However, Southwest Airlines, EasyJet and Ryanair do not distinguish between every seat; all seats are the same. In this context, a seat is actually a value object. Most airlines uniquely distinguish each seat on every flight. In this context, each seat is an Entity.
However, Southwest Airlines, EasyJet and Ryanair do not distinguish between all seats and all seats are the same. In this context, the seat is a Value Object.
If you just want to "visualize" an airplane seat, it should be the same model because the seat is a seat.
However, in this case, the physically the same thing was recognized as a model depending on the service policy of the operating company.
This means that each problem-solving context has changed the focus aspect and the defined model.
It turns out that different airlines may have different perceptions of the model. So are the models always the same within the same airline?
Even if you imagine a little, it seems that the team that physically creates "seats" and the team that manages reservations for "seats" have different views on how to solve the problem of "seats".
If the same range of model recognition cannot be universal, and it is not a company unit, is it a department? team? In the first place, it depends on the person ...?
Thinking this way, you might come to the conclusion that *** you need to explicitly define the scope to which the model applies ***. This explicit demarcation is called *** bounded context *** in Domain Driven Design terminology.
See the definition in Eric Evans' DDD Reference (http://domainlanguage.com/ddd/reference/).
bounded context: A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
Bounded context:
A description of the boundaries (usually subsystems, or the work of a particular team) to which a particular model is defined and applied.
Domain Driven Design attaches great importance to this bounded context. As mentioned above, no model can be defined correctly without this boundary.
It then defines how the contexts relate to each other. The artifact is called a context map. This is the number one base of design in Domain Driven Design.
We defined the model as a word recognition match and described the confusing word-bounded context of DDD.
How will the bounded context be incorporated into the implementation in the future? I would like to write.
Recommended Posts