[JAVA] The story that a model is not a "correct representation of the real world" / the need for a bounded context

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

Introduction

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.

What is a model?

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.

Definition of Eric Evans

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

Case study

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.

Limit the scope of application of the 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.

Summary

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

The story that a model is not a "correct representation of the real world" / the need for a bounded context
The story of making a binding for libui, a GUI library for Ruby that is easy to install
Determine that the value is a multiple of 〇 in Ruby
What is the representation of domain knowledge in the [DDD] model?
A story that struggled with the introduction of Web Apple Pay
[Swift] The story that switch is often used for enum judgment
A story that confirmed the profile of Yasuko Sawaguchi 36 years ago
Summary: Implementation of a function that switches the logical value when a link is clicked [for own output]
The story of introducing Gradle as a retrofit to an existing system that did not manage packages
A story that suffered from a space that does not disappear even if trimmed with Java The cause is BOM
[Must-see for fledgling engineers] A story that the world expanded when I actually operated a web service that I made by myself