[DDD] What is the most accessible architecture to get started with Domain Driven Design?

DDD serialized article

• Why do DDD beginners get sick immediately after getting angry
• 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 start implementing with Domain Driven Design
• Domain Driven + Onion Architecture Overview

Background / premise

In the article Why DDD beginners get disappointed immediately after getting rid of it

There are various architectures introduced in the literature on the net. Hexagonal architecture was mentioned in IDDD, but there are famous variants such as onion architecture and clean architecture that evolved from it. This causes a great deal of confusion when embarking on an implementation. You will spend time understanding the context and choosing the architecture to adopt.

I wrote. Here's an architecture that I consider to be the "most accessible".

As a premise, *** is a personal opinion *** based entirely on personal experience.

In the theory of DDD, regarding the architecture, Eric Evans's domain-driven design <img src =" // ir-jp.amazon-adsystem.com/e/ir?t=majackyy-22&l=am2&o = 9 & a = 4798121967 "width =" 1 "height =" 1 "border =" 0 "alt =" "style =" border: none! important; margin: 0px! important; "/> (the original text below) and <a target = "_ blank" href = "https://www.amazon.co.jp/gp/product/479813161X/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=479813161X&linkCode=as2&tag=majackyy-22&linkId=aff868b58c9e780a12c6e0c Drive design (Object Oriented SELECTION) (Hereafter IDDD) and different ones are introduced, and it is said to be the only correct answer. Nothing is presented. The architecture is left to the discretion of each project, and the suitability depends on the project requirements and members.

However, I think that it will make me wonder how to start when I start, so I will propose * "If a beginner starts, this is good" *. Please note.

Candidate architectures and their relationships

If you catch DDD articles online, you will find the following.

1. Layered architecture
2. Hexagonal architecture
3. Onion architecture
4. Clean architecture

Let me give you a brief overview of these.

Layered architecture

The architecture introduced in the original text. Compared to the traditional three-layer architecture, the idea is to establish a Domain layer and aggregate domain logic there.

Hexagonal architecture

The architecture introduced in IDDD. Also known as "port and adapter architecture". It was originally proposed in 2005 by this blog.

In fact, *** "Hexagonal, Onion, Clean" are essentially the same ***.

The idea is that it is completed with this hexagonal. The only difference is the way the responsibilities are separated and the name. Then, isn't it okay with hexagonal?

That's right, it's basically hexagonal, and as a result, it has the same design.

However ...

*** Doesn't the implementation image come out even if you look at this figure? *** ***

I think this is the point, and I wonder if this confusingness is the reason why people who read IDDD can't move their hands right away.

To put the conclusion in a strange position, *** My recommendation is onion architecture ***. Although this is essentially the same, it is easier to understand intuitively as a result of changing the division of responsibilities and the name, so I think it is better to do the first introduction while looking at this figure.

Next, I will introduce that.

Onion architecture

Following the hexagonal architecture, the onion architecture was proposed in this blog in 2008.

Isn't there an image of what kind of structure it will be? I will explain the details later, but the point is that the Domain layer is no longer dependent on the Infrastructure layer due to the principle of dependency reversal ***. This makes the Domain layer model an implementation that does not depend on a specific library.

This is exactly the same idea in the hexagonal architecture, but it is difficult to read from the conceptual diagram. That's why I recommend the onion architecture to get started first because it's intuitive and easy to understand when looking at the diagram.

It's a weird order, but I'll also show you a clean architecture for comparison.

Clean architecture

Following the hexagonal, onion and other architectures, the clean architecture sought to integrate the concept in 2013. It was proposed in this blog.

The image is taken from the same blog

As you can see from the structure where concentric circles overlap, basically the same thing is said. I think the only difference is the word.

There are some articles that clean architecture is used independently of DDD as the architecture of Android applications.

I really like this, but it's hard to understand what to write in the layer called "Use Case layer", and the naming is "Entity layer" instead of "Domain layer" (Entity is a part of Domain layer in DDD) So it doesn't fit well), so I prefer the onion architecture.

If this fits your needs, I think you should adopt the clean architecture naming.

How to implement using the architecture

About how to pack behavior into the domain layer What is the expression of domain knowledge in the [DDD] model This article introduces it with sample code.

The Task entity in the article corresponds to DomainModel, TaskRepository corresponds to DomainService, and TaskApplication corresponds to Application. Looking at it like this, it's pretty simple, and it's easy to imagine the name and content of the layer.

That's why I try to start with the onion architecture and the sample code as before when I first explain DDD.

I'd like to dig a little deeper into the onion architecture and dependency inversion in another article.

Subsequent article

Domain Driven + Onion Architecture Overview Please take a look here.

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.

"Chapter 5 Architecture" in this book provides a more detailed explanation of the content 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