[JAVA] Answered questions about DDD [Domain Driven Design]

The other day, I visited Media Max Japan (hereinafter referred to as MMJ) and held a Domain Driven Design Study Group. There was a question and answer session there, and I answered various specific questions that came up when I actually started developing with Domain Driven Design. Perhaps many people would have similar questions, so I would like to introduce it here with the permission of MMJ.

How to divide the context

Is it okay to use DB in common for multiple contexts?
Is it okay to not have a schema?

We recommend that you keep the schema at least for each context. Please refer to the following article for details.

Bounded Context Implementation-Domain Driven Design Glossary

Cut for each function? Should the context be separated for each user type?
How can I determine if the context is cut correctly?

Context design does not have a flowchart that can be created according to it. In reality, we need to think from both a conceptual perspective and an implementation perspective. As a heuristic approach, I think it would be better to verify from multiple perspectives as follows.

• Is it appropriate as an area that separates the meaning of the model? Does one model have multiple meanings?
• Cultural and organizational boundaries are hints
• Is it appropriate to divide the domain (problem domain) rather than the context (solving domain)?
• Is there an implementation image as a way to cut the application?
• Think of it as a way to cut microservices
• Is the team size appropriate?
• As a rule of thumb, 6-8 people are said to be the maximum)
• Can you name it well?
• Unnamed means that the concept may be cut incorrectly

Can I share the same model with another context?

"Same model" is not shared.
This is because the definition of a bounded context is "an explicit scope to which one model applies". Sharing in multiple contexts violates this definition.

However, this does not mean that "objects with the same name cannot exist in multiple contexts".

"Define models with the same name but different behavior in each context."

Then, it is necessary to clarify the relationship between the models across the context. This is context mapping.

Validation

How should I write the validation?

There are several types of validation stories. This area is the material I want to write about.

• Domain restrictions → Validate at the domain layer, throw exceptions, and leave the processing to the application
• Application constraints → Write as needed

About Domain Driven Design

Is this writing good? I'm writing while worrying. Is there a best practice?

There is none! Lol (maybe) Domain Driven Design is inevitably involved in the architectural story, which requires a great deal of decision making. At that time, there is more than one option that can be taken in Domain Driven Design, and it is necessary to always consider the advantages, disadvantages and costs and decide how far to incorporate the idea of Domain Driven Design.
Therefore, I wonder if it is difficult to make something that says "this is the correct answer". ..

If you mean "sample code" instead of "best practice", the Practice DDD book has sample code for the book. It may be good to start with this book + sample.

If you do all the domain-driven design properly, you will fall into overdesign. How long should I keep it?

As mentioned above, designing Domain Driven Design is a stack of fine decisions.

Ideally, it is best to understand the advantages, disadvantages, and costs of each time and make a balanced decision. However, there are many things that we do not understand from the beginning, so it is necessary to proceed to some extent. In addition, we may intentionally compromise the design with cost performance in mind.

I think it's important to be able to answer the reason later, not "somehow", when making a proper decision.

About CQRS

Is the data obtained by CQRS query no longer a domain model?

What kind of object should the acquired data be treated as? Yes, it's OK to think that what you get with the query model is not the domain model. Give your query model a name and separate the concepts.

I name the return value of the query XxxDto and don't use the name Dto anywhere else.

In addition, I sometimes see it misunderstood.

*** CQRS does not mean that you cannot make DB queries in the domain model for update processing. *** ***

• Update processing → Inquire DB with domain model and update DB with the same model
• Reference processing → DB query with query model

Is the difference. Please be careful.

How to interact with a domain object with an OR mapper
Currently, jooq is used to implement persistence and loading from DB. Is there a way to omit the implementation?

Regarding the ORM of the domain model, SpringDataJPA is a concept that is quite conscious of Domain Driven Design, and the implementation class of Repository is automatically generated from Interface, so that time and effort can be saved to some extent. It just fights against hibernate specs, so that's what you like.

I think that the advantage of querying is that you actually make an efficient query yourself, so I don't think you can omit the query part. If you use MyBatis, the mapping between the query and the object that receives it will be assisted to some extent.

Purpose of Domain Driven Design

I only know the joy of Domain Driven Design.
What is the priority to protect?

What kind of benefits is the priority? I'll write more about this in another article, but I'll just give you an overview.

First, Domain Driven Design is unsuitable and suitable for "applications with complex business logic." There is a lot of overhead in cases where simple CRUD is enough.

For applications with complex business logic, the source code tends to become complicated and development efficiency tends to decrease as the development progresses. On the other hand, I think Domain Driven Design is a countermeasure to control complicated specifications and code well.

First, let's decide if it fits this purpose.

What do you care about when developing?

Do you think the model is correct

The message of Domain Driven Design is to focus on the model anyway.

So, I don't say "make the modeling appropriate and put out something that works for the time being", but just focus on whether the model seems to be correct.

Which layer is responsible for the implementation

This is a controversial point when designing.

According to the responsibility definition of the domain layer and application layer, "Where should I write this implementation?" Is naturally guided to some extent. You should always think about this during development, and this will create a solid design policy that will help improve implementation maintenance.

Layer responsibilities

The understanding here is ambiguous, so please tell me how to separate it well.

I would like to write this in detail in another article.

• Domain layer: Ensuring the integrity of the business to be systematized
• Domain model: Represents the result of modeling a business   * Entity   * ValueObject   * DomainEvent
• Domain service
• Repository: Model persistence / restoration of objects from persistence destination
• Factory: Object creation (complex things that cannot be left to the entity)
• DomainService: Responsible for not being able to express as one model
• Application layer
• Application service: Meet the specifications by combining operations published by the domain layer

Free to proceed with development

What kind of agreement do customers have when implementing Domain Driven Design in their projects?

It's an in-house service. .. However, since my previous job was at SIer, I will answer based on that experience.

First of all, if it's just about architecture, do we need to get your permission to choose the architecture to adopt? I think that's the only point. If that's not a problem, you can optionally adopt a Domain Driven Design architecture.

The problem is about the development process. Since it is said that domain-driven design should always match recognition through dialogue with domain experts (≒ customers), frequent communication is required. It is necessary to agree with the customer whether this opportunity can be profitable.

However, although this is a complete personal opinion, it is not necessary to explicitly state that "I will do Domain Driven Design", and I agreed on the story that "I want to match this recognition, I need this frequency" I think it's good to take it. It's difficult for even engineers to understand Domain Driven Design, so for now I'm wondering if it's difficult for the business side to understand that much.

What are you doing to share the model with your customers?

The ER diagram is always maintained, but there are only 3 engineers.

I don't share the honesty with the business side. I used to work with the planner at the time of new development, but I didn't match that much when continuing.

If anything, it's just like "let's match the words we use" (≒ ubiquitous language). To be honest, I don't know the image of sharing the model diagram with people on the business side, and after all, the recognition on the screen is the best, so I'm exploring what is good about this.

Event sourcing

Have you introduced it? Is it okay?

I haven't done it yet.

Event sourcing is completely unsuitable for data, so you should make a decision based on that.

For example, purchase history, etc.

• Area where damage is large when trouble occurs
• Transaction type that leaves data

Suitable for. There is no need to make simple processing such as task completion / incompletion into event sourcing, and it is necessary to identify the advantages and disadvantages.

About subdomains

I'm thinking of using keycloak. Should keycloak be treated as a separate bounded context?

I think it is better to think about this area from both the implementation image and the conceptual model. It's definitely a different context if you make it independent as an authentication server.
In that case, how to model the information received from it. Consider whether persistence is necessary.

About the architecture

How to do the architecture three-layer + domain model?

I personally recommend the onion architecture. Please see the following article for details.

What is the most accessible architecture to get started with Domain Driven Design

Domain Driven + Onion Architecture Overview

But in essence

*** If the domain model is written in a form that does not depend on anything, the rest is an error ***

is. After that, I would like you to choose the one that fits the structure and terms.

How to create a domain object from parameters received from the UI layer

First, let's create objects only in the following two patterns.

• When creating a new object: It is recommended to create it with the constructor of the object normally.
• When regenerating a persisted object from DB: Implemented in repository. It ’s better to get some framework power here.

The important thing is that *** persisted objects should not be created with the input values from the screen ***. It is common that the value received from the form of the screen by the update method is packed with the value from the default constructor.

For the domain layer, be sure to expose only the methods that can ensure consistency to the application layer.