DDD基础概念

àì夳堔傛蜴生んèń 2022-09-03 05:18 191阅读 0赞

*  **限界上线文**：指的是一个大系统中的一小块子系统  
    举个例子，一个电商系统就是一个大系统，而其中的订单系统，营销系统，库存系统等等就是其中的子系统  
    每一个子系统都有自己的领域和边界，就可以认为是一个限界上下文
 *  **通用语言**：对于一个限界上下文中一批名词（类）的定义  
    还是以电商系统举例子，假如有一个类叫做Customer，对于订单系统来说，可能就是指的下单客户信息，对于供应商系统来说，可能指的就是内部的供应商客户  
    不同的限界上下文中应该维护一套自己的通用语言，定义自己内部使用的名词和解释
 *  **子域**：每一个限界上下文又可以叫做不同的子域，子域又分为多种类型
    
     *  核心域：顾名思义，就是最核心的，占用资源最多的几个子系统就叫做核心域，比如交易系统，商品系统等等
     *  支撑子域：主要是一些辅助的系统，给核心域提供一些额外支持，比如BI系统，爬虫系统等等
     *  通用子域：使用通用解决方案的系统，比如权限系统，OA系统等等

--------------------

*  **上下文映射**：子域之间如何进行集成和交互，把子域里的通用语言，映射成其他子域里面的通用语言，通过接口来进行转换的过程
    
     *  合作关系（Partnership）：两个系统之间是紧密耦合的，操作要么一起成功，要么一起失败，修改需求的话也需要一起调整
     *  客户方-供应方（Customer-Supplier）：你的系统需要调用其他的系统去开发，这事儿得你们一起协商来做
     *  遵奉者（Conformist）：在使用第三方的系统的时候，比如阿里云，人家已经给你提供了现有的功能，你要么就用现有的接口来实现，要么就别用
     *  共享内核（Shared Kernel）：两个子域使用一个通用的领域模型，维护一个独立的通用工程
     *  开放主机服务（Open Host Service，OHS）：使用开放平台API进行交互
     *  发布语言（Published Language，PL）：类似XML、JSON、HTML之类的，使用这些通用数据格式进行交互，或者是用类似于thrift这种方式，定义一份通用接口，然后生成不同语言的代码
     *  隔离模式（Separate Way）：两个子域完全没关系，就是隔离开来的
     *  大泥球（Big Ball of Mud）：多个子域的模型混合再一起，这就是大泥球

备注：一般基于消息的解耦，都是使用的OHS + PL的形式，基于发布的消息形成一个开放主机服务，消息的具体形式，可以是JSON、XML等格式

*  **防腐层（Anticorruption Layer，ACL）**：一般像合作关系，客户方-供应方还有共享内核这些映射方式，都可以大家一起商量做成什么样的，子域之间进行模型交互的时候，做一层简单的翻译即可；但是如果是遵奉者的话，下游系统就需要一个防腐层，将上游系统提供的模型进行翻译，避免耦合在一起
 *  **实体**：大致就是业务系统里面最核心的一些名词生成的实体类，里面需要有一个唯一标识符来标记  
    举个例子，订单定义为Order，这个Order就是一个实体，里面有一个OrderId作为唯一标识
 *  **值对象**：封装了一堆属性，没有唯一标识符  
    订单中会有不同的商品，组成一个订单条目OrderItem列表，订单与订单条目就是一对多的关系，这里的商品条目就可以认为是一个值对象，值对象没有唯一标识
 *  **聚合**：聚合封装了实体和值对象，其中最重要的实体对象就是聚合根，通过聚合根才能和外部进行交互（隐藏细粒度对象），保证业务规则和数据的一致性。一个聚合不应该过大，保证一个最小聚合的原则，同时聚合里面的各个实体在一个事务中应该是保持一致的。  
    上面的Order和OrderItem就可以组成一个聚合，这个聚合比较简单，只有一个实体和一个值对象，Order就是聚合根，任何对于订单条目OrderItem的操作都需要由Order来进行，而不允许直接操作OrderItem，这样才能保证多个互相关联的对象的一致性（[更多聚合知识][Link 1]）
 *  **领域事件**：领域事件主要是一个承上启下的作用，有助于形成完整的业务闭环，导致进一步的业务操作，使服务之间保持松耦合  
    比如订单支付就可以作为一个领域事件，将订单域和支付域进行了解耦，订单支付这个事件就会触发下一步的支付流程
 *  **领域服务**：某些行为不适合放在一个特定的实体中，那么就由领域服务通过多个实体完成一个完整的业务流程或者逻辑，领域服务中不适合放入过多的业务逻辑，否则就会产生一个贫血模型
 *  **用户界面**：负责向用户显示信息和解释用户命令，常见的Controller就是用户界面（这里的用户界面也可以是其他的计算机系统）
 *  **应用服务**：应用服务接收到用户界面的指令之后，会进行业务流程的编排，里面不应该掺杂其他的业务逻辑，具体的实现逻辑都放到领域服务中实现，以创建订单的伪代码举个例子

pulic void createOrder(Params params) {
        // 参数校验
        orderService.checkParams();
        
        // 保存订单数据
        orderService.saveOrder();
        
        // 更新订单状态
        orderService.updateOrderStatus();
        
        // 锁定库存
        orderService.lockStock();
    }

*  **工厂**：使用工厂模式创建复杂的实体或者聚合
 *  **资源库**：负责对实体/值对象数据进行持久化
 *  **战略设计**：包括限界上下文的划分，不同子域类型的定义，上下文映射进行子域集成，其实就类似于一个概要设计
 *  **战术设计**：包括通用语言的设计，实体/值对象/聚合的设计，还有数据库表设计，类及接口的定义，各种业务流程图、时序图等等，可以认为是详细设计中的一部分

[Link 1]: https://baijiahao.baidu.com/s?id=1652528385112311315&wfr=spider&for=pc