关于java:DDD思维导图

常见相干问题

DDD 概念

• DDD，全称 Domain-Driven Design，是一种解决简单畛域的设计思维，它试图拆散技术实现的复杂性，并围绕业务概念构建畛域模型来管制业务的复杂性，以解决软件难以了解，难以演进的问题。它通过边界划分将简单业务畛域简单化，帮咱们设计出清晰的畛域和利用边界，能够很容易地实现架构演进。

  DDD 是面向对象的设计思维，是面向对象设计的一种升华。

• 畛域驱动设计提出了一套外围结构块（Building Blocks，如聚合、实体、值对象、畛域服务、畛域工厂、仓储、畛域事件，等）, 这些结构块是对面向对象领域建模的一些外围最佳实际的稀释。这些结构块能够使得咱们的设计更加规范、有序。

实体(Entity) & 值对象(Value Object)

实体与面向对象中的概念相似，在这里再次提出是因为它是畛域模型的根本元素。在畛域模型中，实体应该具备惟一的标识符，从设计的一开始就应该思考实体，决定是否建设一个实体也是非常重要的。值对象和咱们说的编程中数值类型的变量是不同的，它仅仅是没有惟一标识符的实体，比方有两个播种地址的信息齐全一样，那它就是值对象，并不是实体。值对象在畛域模型中是能够被共享的，他们应该是“不可变的”（只读的），当有其余中央须要用到值对象时，能够将它的正本作为参数传递。

服务

当咱们在剖析某一畛域时，始终在尝试如何将信息转化为畛域模型，但并非所有的点咱们都能用 Model 来涵盖。对象该当有属性，状态和行为，但有时畛域中有一些行为是无奈映射到具体的对象中的，咱们也不能强行将其放入在某一个模型对象中，而将其独自作为一个办法又没有中央，此时就须要服务。服务是无状态的，对象是有状态的。所谓状态，就是对象的根本属性：高矮胖瘦，年轻漂亮。服务自身也是对象，但它却没有属性（只有行为），因而说是无状态的。服务存在的目标就是为畛域提供简略的办法。为了提供大量便捷的办法，天然要关联许多畛域模型，所以说，行为 (Action) 天生就应该存在于服务中。服务具备以下特点：

1. 服务中体现的行为肯定是不属于任何实体和值对象的，但它属于畛域模型的范畴内
2. 服务的行为肯定设计其余多个对象
3. 服务的操作是无状态的

模块

对于一个简单的利用来说，畛域模型将会变的越来越大，以至于很难去形容和了解，更别提模型之间的关系了。模块的呈现，就是为了组织对立的模型概念来达到缩小复杂性的目标的。而另一个起因则是模块能够进步代码品质和可维护性，比方咱们常说的高内聚，低耦合就是要提倡将相干的类内聚在一起实现模块化。模块该当有对外的对立接口供其余模块调用，比方有三个对象在模块 a 中，那么模块 b 不应该间接操作这三个对象，而是操作裸露的接口。模块的命名也很有考究，最好可能深层次反映畛域模型。聚合 聚合被看作是多个模型单元间的组合，它定义了模型的关系和边界。每个聚合都有一个根，根是一个实体，并且是惟一可被外拜访的。正是如此，聚合能够保障多个模型单元的不变性，因为其余模型都参考聚合的根。所以要想扭转其余对象，只能通过聚合的根去操作。根如果没有了，那么聚合中的其余对象也将不存在。一个简略的例子如下：customer 是该聚合的根，其余的都是外部对象，如果内部须要用户地址，拷贝一份传递进来即可。不言而喻，用户如果不存在，其余信息均无意义。

工厂

在大型零碎中，实体和聚合通常是很简单的，这就导致了很难去通过结构器来创建对象。工厂就决解了这个问题，它把创建对象的细节封装起来，奇妙的实现了依赖反转。当然对聚合也实用（当建设了聚合根时，其余对象能够主动创立）。工厂最早被大家熟知可能还是在设计模式中，确实，在这里提到的工厂也是这个概念。然而不要自觉的去利用工厂，以下场景不须要工厂：

1. 结构器很简略
2. 结构对象时不依赖于其余对象的创立
3. 用策略模式就能够解决

仓库

仓库封装了获取对象的逻辑，畛域对象毋庸和底层数据库交互，它只须要从仓库中获取对象即可。仓库能够存储对象的援用，当一个对象被创立后，它可能会被存储到仓库中，那么下次就能够从仓库取。如果用户申请的数据没在仓库中，则会从数据库里取，这就缩小了底层交互的次数。

对立语言

对立语言（Ubiquitous Language），是畛域驱动设计中一个十分重要的概念。任何一个畛域驱动设计的我的项目，都须要一种通用语言，一套通用的词汇。因为没有通用的语言，就没有统一的概念，沟通就会遇到阻碍，最初的畛域模型和软件也就无奈满足畛域内的实在业务需要。通用语言是领域专家和开发人员在对畛域问题的沟通、需要的探讨、开发计划的制订、畛域模型的设计，以及开发人员之间对畛域模型的具体编码落地实现，等一系列过程中，所有人员应用的一种通用语言。话句话说，就是无论是沟通时所用的词汇、还是畛域模型中的概念、还是代码中呈现的类名与办法，只有是雷同的意思，那就应该应用雷同的词汇。能够看出，这种通用语言不是一下子就能够造成，而是在一个各方人员探讨的过程中，一直发现、明确，与精炼进去的。

模型驱动设计

• 分层架构：UI 层，应用层，畛域层以及基础设施层。

1. UI 层（User Interface）负责向用户展示信息，并且会解析用户行为，即常说的展示层。
2. 应用层 Application Layer 应用层没有任何的业务逻辑代码，它很简略，它次要为程序提供工作解决。
3. 畛域层 Domain Layer 这一层蕴含无关畛域的信息，是业务的外围，畛域模型的状态都间接或间接（长久化至数据库）存储在这一层。
4. 基础设施层 Infrastructure Layer 为其余层提供底层依赖操作。层构造的划分是很有必要的，只有清晰的构造，那么最终的畛域设计才宜用，比方用户要预约航班，向 Application Layer 的 service 发动申请，而后 Domain Layler 从 Infrastructure Layer 获取畛域对象，校验通过后会更新用户状态，最初再次通过 Infratructure Layer 长久化到数据库中。

DDD 设计的步骤

1. 依据需要划分出畛域、限界上下文；
2. 剖析每一个限界上下文中的实体、值对象；
3. 聚合实体、值对象，划分出聚合范畴、聚合根；
4. 设计聚合根的仓储；
5. 实际操作，一直反馈，迭代模型