DDD与微服务架构

一、绪论

   由于本人有过微服务架构方面实战的经验，且公司方面当前项目架构为DDD，故本文从微服务架构出发，探索DDD与微服务架构的异同以及如何实践DDD。

二、为什么使用领域驱动

在使用DDD前，我们首先需要弄明白DDD的意义即我们为什么要去使用DDD。

采用DDD的设计思想，业务逻辑不再集中在几个大型的类上，而是由大量相对较小的领域对象组成，这些类具备自己的状态和行为，与现实领域的业务对象映射。基于领域驱动的设计，保证了系统的可维护性、可扩展性和可复用性，在处理复杂业务逻辑方面有先天的优势。
领域模型是领域驱动的核心。领域模型通过聚合（Aggregate）组织在一起，聚合间有明显的业务边界，这些边界将领域划分为一个个界限上下文。

三、相关技术概述

2.1、实体
实体是领域中需要唯一标识的领域概念，实体有生命周期，实体被创建后可能会被持久化到数据库。
2.2、值对象
用程序的方式来表达就是，如果两个对象的所有属性都相同，则被认为是同一个对象，那么我们就可以把这种对象设计为值对象。因此，值对象没有唯一标识，这是它和实体最大的不同。
2.3、聚合及聚合根
聚合定义了一组具有内聚关系的相关对象的集合，一个聚合中可以包含多个实体和值对象，因此聚合也可以称为根实体。
聚合根是DDD中得到一个概念，是一种更大范围内的封装，把一组有相同生命周期、在业务上不可分割的实体和值对象放在一起考虑，只有根实体可以对外暴露引用（这是一种内聚性的表现）
2.4、边界上下文
每个领域实体都有属于自己的边界上下文（context），它明确限定了每个模型的应用范围，在context中模型在逻辑上要统一，而不用考虑它是不是适用于其他context（其含义见例子），不同context下的业务相互通信涉及到跨边界的集成，集成不是简单的RPC服务调用，而是需要一个专门的防腐层做转化。
举例：会员在网站A表示买主，在网站B表示客户，虽然很多属性是一样的，但是二者在不同的context下语义和概念是有差别的，需要用防腐层做转换。
2.5、仓储/资源库
领域模型中的对象不会一直在内存中活动，当它不活动时会被持久化到数据库中，然后当需要的时候我们会重建该对象，重建对象就是根据数据库中已存储的对象的状态重新创建对象。
仓储里存放的对象一定是聚合，只为聚合设计仓储。
仓储的重要特征是分为仓储定义和仓储实现部分。这样设计的原因是：仓储背后的实现都是在和数据库打交道，但是我们又不希望调用方（如应用层）把重点放在如何从数据库获取数据的问题上。

2.5、Pojo，Bo
POJO:简单对象，专指只有 setter / getter / toString 的简单类
BO: 主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。

四、逻辑架构图

五、微服务架构于DDD联系

（1） 限界上下文相当于微服务架构里的一个微服务项目进程，多个限界上下文组成一个领域，不同领域之间有明显的边界划分
（2）在微服务设计时应该首先识别出DDD中的聚合根
（3）在微服务之间集成时应采用DDD中的防腐层