What is domain driven design?

What is domain driven design?

You may use domain-driven design (DDD) has developed a number of projects. You may be satisfied with
the use of the domain model to develop the field of business. And proudly show it to your colleagues to see, they will say "666."

But sometimes you use 领域模型you always feel where a bit wrong. You'll whisper you may have missed something.
emmmm ... but is it really? You find yourself asking these questions like the following:

  • What is a domain model?
  • Domain model is how to update the database it?
  • Domain model whether to introduce an architectural pattern? E.gCQRS

When I first started using the 领域模式time, I also was plagued by these questions above.
Even when a few days ago I wrote a document, I do not have a solid understanding and some details.
I went through some "aha" moment of resuscitation, I want to share with you these.
This article will help you understand the in-depth explanation of the answer to the above question.

Before looking at the answer, we need to take a step back.
The purpose of this article is not to give you a checklist, but want to help you really understand the domain model.
In fact, we do not have much to learn, in fact, we spend a lot of time trying to forget some of the concepts already learned (unlearning).

"Forget that you have learned." - Yoda

image

This article really long. It is more like a mini book, which is why I prefer the form.


Summary

If you do not want to read the entire article, you can quickly browse this summary. If you intend to read the entire article, you can skip this part.

Question: What is the domain model?

A model to solve the problem at the scene formed, and then use this model to solve business problems.
According to duplication of work experience we will form a pattern. Domain model too will form a pattern, he includes: entities, value objects, modules, field service.

Question: domain model is how to update the database it?

Using the Repository ( repository) to update the domain model database.
In one 一对多entity, for example: a user group ( Group) and user ( User), there are N users in the user group,
if the user is very large, a load Groupcertainly cause performance loss, this problem is how to design it?
If you do not use the domain model will rely on the experience you think of the split, and now you want to use the domain model programs should be split.
I saw some people repositoryinjected into the domain model, this approach is wrong.

Question: Are the domain model to introduce an architectural pattern? E.gCQRS

First of all I want to say is the domain model does not require the introduction of architectural pattern.
Field mode is to solve business problems in the field, he is not to solve architectural problems, so the domain model itself does not require the introduction of architecture.
When you use the domain model, you can use on the field layer architecture, for example CQRS, MVCand so on.


Otherwise, we begin the text. I would like to explain the traditional start of the project a step by step transition to the domain model.
I will explain the code structure three tissues are: the traditional model, IDDDmodel, I think the model.

Talk about technical framework we use:

  • ORM: Spring Data JPA
  • Database:h2-database

Let's assume that a demand for the use case, and now we have to develop a functional identity module (identity) which have included
obtaining user information, change passwords, user authentication.

Using traditional project to develop the entire demand

First, look at our project structure:

image

The project structure we have been very familiar with, that is our traditional hierarchical fashion.
We will usually write business logic inside the service, as follows:

image

整个功能我们已经开发完了,是不是看着非常简单。
我们来看changePassword方法,我们通过repository根据用户名获得到用户,
然后调用authenticate方法进行认证,认证通过后修改密码(user.setPassword())。
是不是看上去没有任何毛病,而且程序还运行的非常成功。嗯,确实是。
但是在这种编程模式里我们更多的是从数据库的模式来开发的,因为User只是封装了静态数据。
然后在service中来完成修改密码这个逻辑,这种操作更像是过程化编程。

我们应该从面向对象的角度来思考问题。
一提到对象你首先想到的是什么?继承?封装?多态?还有吗?
我再添一条类是一组相关的属性和行为的集合

既然我提到了属性和行为,那我们重新思考下修改密码这个用例:
首先passwordUser类上的一个属性,对于修改密码我们应该是调用User对象上的changePassword方法,
然后由changePassword来完成修改password属性,这就是封装。

接下来我们使用领域模型再来完成上面用例的业务。

使用IDDD来开发整个需求

首先我们也是来看一下IDDD的项目结构:

image

当你看到这个项目结构的时候,你可能心生疑惑:“怎么没有service, repository这样的包呢?”

我来告诉你,IDDD推荐我们使用应用层、领域层和基础设施层来做分层。
对于这种分包方式是《实现领域驱动设计》这本书比较推荐的。所以这个项目我们以这种方式来组织我们的代码。

接下来我们来看看应用层服务和领域模型:

image

image

再来看UserService上的changePassword方法,我们还是通过authenticate获得用户,
然后又调用了用户的changePassword来修改密码。

但是你会发现我们并没有把密码加密这个交由User来完成,这是为什么呢?

因为加密不是User的职责。就像authenticate一样,你自己不可能认证自己,
就像你不借助镜子永远不会看清你的脸蛋。就像你会问别人我今天漂不漂亮,而不会自欺欺人的告诉自己我很漂亮。

通过将changePassword交由User,你会发现你的业务很清晰了。
因为你对号入座将原本由用户该做的事情又还给了用户。

接下来我想说一个我认为的分层架构,以及如何组织代码。这部分知识涉及到了UML、面向对象。

我直接上图,然后在细细讨论:

image

当你看到这个结构,你会发现怎么没有层了呢?怎么都放在了一个包里。
聊到这我就应该给你说一说UML中的模块和构造型。
我们都已经很熟悉模块了,因为我们平常都是在用包来组织模块。
这个我就不多讲了,我想说的什么是构造型。构造型就是用来区分不同种类的类。
玩了那么多年的Spring,还记得那几个常用的组件注解(@Component@Controller@Service@Repository)吗?
他们被放置在org.springframework.stereotype这个包下,就是为了区分你的不同种类的类。

所以我们现在为我们的模块(identity)画一个UML的类图:

image

image

When you see the UML class diagram again and Java project structure diagram is not just compare some clear it?
This time you can together with a use case and sequence diagram to express your business.

image

The entire sample source code

what-is-a-domain-model-example

End

Having also generally the whole process of evolution, and this is my year technical summary of it.

To understand a doubt in his heart:. "Why organizational structure of the code structure and framework of our foreign open source project has so much different then,"
I spent a year reading the time: "Domain Driven Design", "realization field driven design ", "
enterprise application architecture "," software modeling and design "these books, in fact, there is no reading of watching.

When you want to get to know a thing, you should get him fully, and then say how you look at it.
Sometimes I later read DDD, I would ask myself, this is what I want to do? This occurs doubts still need to climb,
you should choose to continue to study this book references to other knowledge dissemination, knowledge may be also be paper books.
When the idea of watching these iterations, you have to go back and look at this issue, go try to figure out. There may be a new breakthrough.
The only way to break through again and again, to resolve doubts in your heart.

There are many details I could not have eleven expression.
The evolution of the above represent only my personal thinking, prohibited reproduced, if at the fraught, please point out.

For questions, please add QQ group discussion:

image

Released four original articles · won praise 0 · Views 37

Guess you like

Origin blog.csdn.net/tgioer/article/details/104211228