DDD概念以及微服务划分

目录

DDD简介：

DDD与微服务的区别：

DDD核心概念：

如何划分微服务边界：

---

DDD简介：

DDD 是 Domain-Driven Design 的缩写，称为领域驱动设计。它是为了解决划分业务边界的问题,是一种架构模式,也是一种划分业务领域范围的方法论。

DDD与微服务的区别：

DDD 是一种架构设计方法，微服务是一种架构风格。两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

DDD核心概念：

领域：是一种特定的范围，用来确定边界的。如电商领域、外卖配餐领域、保险领域等等。

子域：子域是领域的细分，子域还可以再继续细分，成为子域的子域。如电商领域的订单、商品、物流等子域。子域根据重要性和功能划分为三类子域，它们分别是：

核心域：决定产品和公司核心竞争力的子域。

通用域：没有太多个性化的诉求，同时被多个子域使用的通用功能子域。

支撑域：不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域。

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。

通用语言：通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。通用语言会贯穿整个项目设计过程，并且体现在代码命名中，能够将业务需求准确转化为代码设计。通用语言在不同语境会产生不同的意思，需要在特定的上下文中使用。

限界上下文Bounded Context：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。

理论上限界上下文是微服务设计和拆分的主要依据，但还需考虑团队、技术等外部因素

实体Entity：拥有多个属性、操作或行为的载体，并且有唯一标识符，有唯一id的一类对象。

值对象ValueObject：实际是一种不变的数据集合，与实体一起构成聚合。如地理位置、行政区划、币种、行业、职位等；体现在程序中就是常量、枚举、数据字典。

(可变性是实体的特点，而不变性则是值对象的本质。)

充血模型：模型对象不仅仅是一个数据结构，还包含了业务逻辑和操作数据的方法。好处是将业务逻辑和数据操作封装在一个对象中，使得代码逻辑更加清晰。

充血模型对开发人员有更高的能力要求，要有较强的团队协作能力，有强大的技术中台支撑

贫血模型：与充血模型相比，贫血模型就比较简单与直接。所有业务处理过程都交给 Service 去完成。

工厂：主要的工作是通过装配，创建领域对象。

仓库：为了解耦应用逻辑和基础资源，在基础层和上层应用逻辑之间会增加一层，这一层就是仓储层。

通过仓库与工厂实现聚合，对原有的 DAO 进行了一层封装，在保存、装载、查询等操作中，加入聚合、装配等操作。并将这些操作封装起来，对上层的客户程序屏蔽。这样，客户程序不需要以上这些操作，就能完成领域模型中的各自业务。技术门槛降低了，变更与维护也变得简便了。

聚合：代表在真实世界中的整体与部分的关系。比如，Order（订单）与 OrderItem（订单明细）就是一个整体与部分的关系。当加载一个订单时，应当同时加载其订单明细，而保存订单时应当同时保存订单与订单明细，并放在同一事务中。订单与客户、客户地址等信息不存在聚合关系。

聚合根：把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。

事件风暴（会议）：通常产研与业务人员一起，通过头脑风暴会议，首先列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。

如何划分微服务边界：

以前刚开始学微服务的时候，都是使用了电商微服务例子，一上来就是

1.用户微服务：负责用户信息的管理，包括用户的积分属性。

2.支付微服务：负责订单支付相关的具体业务。

3.商品微服务：负责商品的展示，推荐，搜索逻辑。

4.订单微服务：负责订单创建，管理，积分抵扣优惠券等实际商品价格的逻辑。

5.库存微服务：负责商品库存管理。

6.物流微服务：负责该订单商品的物流服务。

然后每个微服务使用不同的数据库，每个库有不同的表，我愿称之为”电商架构设计规范“，但是从来不知道这个规范是怎么来的。

假如换了个场景，不再是做电商平台，而是做微博、支付平台、广告平台、物联网等等场景的微服务呢，又该如何划分微服务边界？可以遵循什么规范？

选择DDD领域驱动设计划分微服务边界！

我们可以用三步来划定领域模型和微服务的边界。

第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。

第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。

有了这两层边界，微服务的设计就不是什么难事了。

在战略设计中我们建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的关系。到这儿，业务端领域模型的设计工作基本就完成了，这个过程同时也基本确定了应用端的微服务边界。

在从业务模型向微服务落地的过程中，也就是从战略设计向战术设计的实施过程中，我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。

学习摘录《DDD实战课》、《DDD微服务落地实战》