一.DDD是什么？
Domain-Driven Design ： 领域驱动设计
适合的场景：
【复杂】软件的设计之道
个人理解：我认为这个【复杂】至少是一个庞大的业务系统，多个微服务之间有依赖或者影响关系的这种
二.名词理解
值对象（value object）：
可能被持久化，也可能不被持久化
不需要标识，不可变，用来描述事物。
比如：策略，订单中的地址，迭代的概念
实体（Entity）：
会被持久化，实体不一定有全局唯一标志
聚合（aggregate）：
是一组相关对象的集合，一组相关对象应该具有相同的生命周期。
聚合根
聚合根是实体，外部对象只有持有聚合根的引用，聚合内部对象可以持有其他聚合根的应用。
领域服务【Domain Service】
不会被持久化，无状态，不是实体或者值对象的自然职责。是指一个动作
应用服务【Application Service】
无副作用函数
不修改状态，幂等
柔性设计
通用语言
通用语言是很重要的，在不同领域熟悉的人进行交流的时候，统一语言才能让交流顺利，不然最后聊了大半天，发现说的都不是同一个东西，会让交流大打折扣。也许甚至影响到整个项目的最终效果。这个统一语言不仅仅是指某些技术。包括产品经理，项目负责人，开发，测试，在每个环节都需要统一语言。如果产品和开发不统一语言，也许做出来的产品并不是产品经理想要的。在统一语言的过程中，不同领域熟悉的人可以对该语言描述的对象进行补充，这样也可以让参与者更多的了解到这个语言描述对象的详细信息。
建模
传统mvc我们是用的数据建模，ddd是领域建模
关于微服务设计：
- 传统MVC
controller - service - modal(Dao)
按照这个方式我们做一个接口应该是
class PeopleController{
public void updateBasicMessage(String name, int age){
PeopleService.updateMessage(String name , age );
}
}
class PeopleService{
public void updateMessage(String name){
People people = PeopleDao.getOne();
people.setName(name);
people.setAge(age);
if(age>18){
people.identity("身份证")
}
PeopleDao.update(people);
}
}
- DDD 的方式去设计一个接口
class PeopleService{
public void updateName(String name){
PeopleEntity peopleEntity = PeopleDao.getOne();
// peopleEntity自己去做一个更新自己信息的操作
peopleEntity.updateMessage(namea,age);
PeopleDao.update(peopleEntity);
}
}
所有对象自己的操作，应该由对象自己完成。
class PeopleEntity{
private String name;
private int age;
public PeopleEntity updateMessage(String name, int age){
this.setName(name);
this.setAge(age);
if(age>18){
this.identity("身份证")
}
return this
}
}
PeopleEntity就是一个聚合根
上面的PeopleEntity就是一个充血模型
如果这个PeopleEntity里面只有属性和属性的getset就是一个贫血模型
people 对于自己的操作，不应该由servcie去把控，应该由people自己去cover，外部不需要关系people的属性，只需要调用更新的这个方法就可以。
这两种设计的区别：
传统模式 service 的逻辑会不断变的庞大复杂，即使service 我们可以不断的拆，但是只要有逻辑进来，这个servcie都会慢慢变的很庞大
- 领域事件
如果某个事情影响了别的领域做什么行为操作，应该再外部抛出一个事件去出发，而不是糅合在一起。 比如A 是用户去更新了身份证信息，那么影响了银行卡登记的信息，这个时候就应该是由A结束后去抛出一个事件。让银行卡自己更新
ddd的依赖应该是只能依赖相邻一层
事件风暴：
领域事件：（Domain Event）
业务上真实发生的事情。对系统内部或者外部造成的影响。一般用特定方式(已发生的时态)表达发生在问题域中的重要事情 eg: XX已XX 的句式。
只关心专业领域内发生的事情，比如整个淘宝商城，我作为客服来说，我只关心用户的一些反，比如：用户已投诉，投诉已撤销等，但是作为物流平台，我至关心货物是否发送，或者到用户手上，比如；商品已发货,商品已签收，作为淘宝平台，我只关心商品已加入购物车，商品已下单等等。不同的领域只关心自己领域内部的事件。这些事件就是领域事件决策命令：
决策命令(Decision Command),是领域事件的触发动作。
可以是由某个角色，或者外部系统，定时任务等触发的操作，是个动词
比如：下单，发货... 这些都是命令识别领域名词
识别限界上下文
就是对一系列领域名词的一个划分
比如上述出现的客服相关的，应该被划分在客服上下文，订单相关的属于订单上下文，物流相关的属于物流上下文... 但是某些上下文会有重叠的地方，比如订单里的商品发货。对于物流上下文来说这是一个出库，但是对于物流来说是已发货，对于这种边界要有清晰划分梳理限界上下文的依赖关系
看上下文之间的依赖关系，某些上下文是否需要修改识别弹性边界
划分问题子域
