代码层级编写规范

1、什么是领域驱动？

核心是维护一个反应领域概念的模型，然后通过大量模式来指导模型设计与开发。

一般过程：通过产品同学所写出的prd，利用领域模型的概念与业务相结合，完善出xmind，现在包括五层：adapter、domain、app、client、infrastructure，其中最重要的就是我们的domain层，下面我们会一层一层的进行描述与每个层级编写的规范；

2、为什么要使用领域驱动（好处）？

1）方便代码的理解、减少新同学接触这方面业务的时间

领域驱动是根据业务延伸出来的，我们在创建业务的实体时，属性、值对象都是可以一一映射到业务上，这样更能令整个代码层次以业务的方式立体的展示出来，这样也能让新接触的同学通过代码直观的了解业务，修改代码也更简单；

2）对业务的迭代更清晰；

3）领域分层主要是将表现层、业务实现层、底层数据实现层，从上到下都有一个接口可以令下一层实现上一层的接口，这样便于之后的工程拆分，极大的增强了项目的伸缩性和扩展性；

例如：若我们现在的数据实现层是利用mysql实现的，以后我们想换一个工具实现，那么就可以很轻松的办到；

4）结构清晰，业务描述清晰；

3、如何使用（pom.xml引用）？

示例：如果mf-custoemr项目之中我们会用到mf-deliver项目的业务聚合，我们需要将mf-deliver对外提供接口的项目mf-deliver-client引用到我们的app层的pom.xml文件之中；

<dependency>

<groupId>com.mfexpress.rent.deliver</groupId>

<artifactId>mf-deliver-client</artifactId>

</dependency>

为了便于版本的控制，我们需要在我们最外层的pom.xml之中也要进行引用；

<dependency>

<groupId>com.mfexpress.rent.deliver</groupId>

<artifactId>mf-deliver-client</artifactId>

<version></version>

</dependency>

4、分层规范（包括包名、层次之间传递数据格式命名规范）：

 

数据基础层 -> 领域层 ： DTO

领域层 -> 适配层：VO

5、名词解释

1）实体（Entity）：以前实体作为直接反映数据库表结构的对象，但是在DDD之中就不完全是一个概念了；

对于实体Entity，实体核心是用唯一的标识符来定义，而不是通过属性来定义。即使属性完全相同也可能是两个不同的对象。同时实体本身有状态的，实体又演进的生命周期，实体本身会体现出相关的业务行为，业务行为会实体属性或状态造成影响和改变。

例如两个student数据，只要id唯一表示不同，就是两个不同的实体；

2）值对象（Vo）：没有唯一标识，生命周期围绕着实体，对实体进行一些属性的延伸，但又不完全属于该实体（自己理解）；

示例：例如客户列表之中，除了客户的自身信息名字、电话之类的属性之外，还有发票、认证信息之类的外部属性，那么我们完全可以把发票、认证信息作为一个值对象；

3）聚合根：聚合根具有全局的唯一标识，而实体只有在聚合内部有唯一的本地标识，值对象没有唯一标识，不存在这个值对象或那个值对象的说法；

（自己理解）聚合根就是将实体和相应的值对象组装起来的一个类，例如：客户列表的聚合根就是客户的实体信息 + 发票信息 + 认证信息；

4）聚合：（自己理解）就是将同一种聚合根的操作，例如对订单的crud；

6、示例：

分层详情