关于DDD的思考

一.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),是领域事件的触发动作。
可以是由某个角色，或者外部系统，定时任务等触发的操作，是个动词
比如：下单，发货... 这些都是命令
识别领域名词
识别限界上下文
就是对一系列领域名词的一个划分
比如上述出现的客服相关的，应该被划分在客服上下文，订单相关的属于订单上下文，物流相关的属于物流上下文... 但是某些上下文会有重叠的地方，比如订单里的商品发货。对于物流上下文来说这是一个出库，但是对于物流来说是已发货，对于这种边界要有清晰划分
梳理限界上下文的依赖关系
看上下文之间的依赖关系，某些上下文是否需要修改
识别弹性边界
划分问题子域