Series Article: Domain Driven Design Explanation Series
What is the most accessible architecture to get started with Domain Driven Design-little hands' lab
Domain Driven + Onion Architecture Overview --little hands' lab
As I wrote in these articles, I'm DDD We use the term onion architecture when deciding on a layered architecture for. I've explained it to various people so far, and I've talked about layer responsibilities as a point that makes it easy to get stuck in understanding, so I will explain that.
Onion Architecture Is Interesting - DZone Java
Description of each layer written in this article
Japanese translation
I've explained it to various people so far, but in many cases I couldn't get it right with the above explanation. Especially when I say *** application-specific logic ***, the word "application" is ambiguous, so people receive it differently, and it doesn't seem to fit well.
Therefore, recently, I have focused on the topic of responsibility and tried to explain as follows.
It may be a little misleading or counter-arguing to say that the responsibility of the domain layer is "data integrity", but I dare to say this with an emphasis on ease of communication.
I will explain in detail below.
What does it mean to "ensure data integrity" at this layer?
For a concrete code example, please refer to the article What is expressing domain knowledge in a model. However, we aim to "only expose methods that can ensure consistency to the upper layer (do not make visibility public).
In the example of the above article, the rule of data integrity is that "a task can be postponed only three times, one day at a time." In order to guarantee this, it is necessary to perform controls such as "record the number of postponements when postponing a task" and "check the number of postponements so far before postponing and make an error if it exceeds 3 times".
A method that does not guarantee this is something like "You can freely change the due date without considering the number of task postponements at all". This is exactly what it is like to publish all setters with public settings, like ActiveRecord pattern objects.
By making only the methods that can be controlled correctly public, we aim for a state where "no matter how hard the upper layer works, the data integrity cannot be broken".
I wrote that the responsibility of this layer is to "combine the methods exposed by the domain layer and build a use case".
How is this different from the responsibilities of the domain layer?
To give another example, let's say the domain layer exposes a "method to change a user's address" and a "method to change a landline number" as independent public methods.
This means that the domain layer "allows the address and landline number to be updated independently for the sake of data integrity."
On the other hand, in the application layer, the following use cases can be realized by combining the above methods.
Whether you want the update operation to be performed independently or at the same time can be freely combined in the application layer according to the use case you want to realize.
Conversely, if the domain layer says, "For data integrity, addresses and landline numbers can only be updated at the same time," the application layer will have to comply.
Use cases (especially in your own web application) can change in a short cycle depending on the policy. But will the integrity of the data change accordingly? The answer would be no. By confining items with different life cycles in each layer, the design can be made resistant to change.
Finally, I would like to write about the merits of why such layering is done.
When designing a DDD, it is always necessary to think about "where is this responsibility?" That is a super important concept that is central to DDD's layering design. Please use it as a reference when designing.
Recommended Posts