领域驱动设计--- 基本概念及战略建模

Posted 2021-05-01 企业云转型之道

在开发一个微服务之前，我们要设计微服务。设计微服务和领域驱动设计（DDD）有密切的关系，DDD有助于我们设计微服务，所以我们这一节主要讲下领域驱动设计的基本概念、建模方法、架构等，以对我们设计微服务提供指导。

领域驱动设计DDD是目前比较火的一个软件架构术语，在我看来，这个其实是业务驱动IT的一个具体体现。DDD的核心思想是在做IT设计之前，要对业务有深入的理解。DDD告诉了我们领域建模的方法并理论化。

1. DDD的基本概念

1）领域：领域就是一个组织所做的事情以及其中包含的一切，每个组织都有它的做事方式和业务范围，这个业务范围及在其中所进行的活动便是领域。对领域最了解的是业务专家，而不是IT人员。

2）模型：对领域的抽象和提炼，是对领域问题的思考过程的总结，由业务分析人员完成。模型承上启下：向上，业务分析人员需要用模型和业务专家沟通；向下，业务分析人员用模型指导软件设计师进行设计并开发软件。模型的首要要求是一致性，同一模型必须是一致的、保持不变的。

3）上下文：可以认为是模型的势力地盘，我的地盘我做主，大家要各司其职，不要越界。使用一个模型之前要进行哪些操作，使用一个模型之后要进行哪些善后。每个模型都有缺省的上下文，当业务比较复杂，特别是要和存续系统对接时，模型的上下文边界就很重要。

2. 领域驱动设计的战略建模（原则）

也可以说是原则，但我更愿意称之为战略建模，就是在项目开始要从宏观的层面划分清楚业务领域，各业务领域能各自为政（限界上下文），独立进化，对外又能形成一个统一的有机体（上下文映射）

1）限界上下文：

把模型的上下文限定在一定范围，模型负责哪些事情，不负责哪些事情有清晰的定义。界定模型的上下文的原因是保持模型的一致性，不会受外界因素的干扰。在《领域驱动设计》一书里，将限界上下文比喻成细胞膜，很形象："细胞膜不仅仅能把细胞内部和外部区分开，而且还能决定通过的物质"。

一般根据下面的因素界定模型的上下文：团队的组织结构、现有的代码库模块的划分、数据库的Schema等。推荐的做法是为每个领域创建一个独立的模型，该模型的上下文是该领域或该领域的子集。

2） 上下文映射：

描述不同的上下文之间的交互关系。业务领域之间不是老死不相往来，相反，业务领域之间存在各种各样交互。交互有下面的类别：

      a）共享内核：两个或多个限界上下文共享同一模型子集及模型相关联的逻辑、代码。团队之间需要统一共享，并且对共享内核的修改要征得另外团队的同意。

      b）客户-供应商关系：两个限界上下文是上下游的关系。处于下游的限界上下文（客户）严重依赖于处于上游的限界上下文（供应商）的输出，比如在电商领域，报表限界上下文严重依赖于在线购物限界上下文的输出（输出会保存到数据库里“客户”和“供应商”应定时安排会议，”客户“提交自己的需求，”供应商“对”客户“的需求进行排期开发。“供应商”会开发一些自己不需要但是“客户“需要的功能和接口。接口是联系“客户”与“供应商”的纽带，需要好好维护。

      c）顺从者：在客户-供应商关系里，当供应商没有意愿满足客户的需求时，客户只能被动接受供应商提供的模型和接口。供应商毕竟有自己要处理的事情，不可能靠“利他“理念推动供应商一直满足客户的需求。”利己“是人的天性。对于“客户”，可以走的一条路是自力更生，创建自己的模型满足自己的需求，并逐步减少对“供应商”的依赖。一旦”客户“有了自己的模型，需要防崩溃层进行对”供应商“提供的接口进行翻译转换。

      d）防崩溃层／反腐层／缓冲层：当客户-供应商关系变为”顺从者“关系，或者需要和存续系统进行交互时，需要防崩溃层对上游提供的信息和数据做出翻译，类似于《设计模式》里的Adapter。“客户”的防崩溃层通过调用“供应商”提供的服务来获取所需的数据或信息，经过防崩溃层的翻译、转换、适配，转变成和“客户”端内模型一致的数据。

     e）隔离通道：当两个系统之间没有或者很少交集，或者没有上下游关系时，或者系统之间集成的难度很大而价值很小时，就可以考虑隔离通道。每个系统都可以用如一个大型企业里的人力资源领域、供应链领域、社区领域。当我们拿到一个新的需求时，我们应该思考可否把它划分为两个或多个没有相通之处的部分。如果可以，我们可以创建独立的限界上下文，并独立建模。

     f）开发主机服务：当有上下游关系，不论是在客户-供应商或者顺从者关系下，作为供应商需要将和外面限界上下文交互的实体、逻辑包装成服务开发出去。应该定义一种协议，并将该协议开放出去，这样其它上下文都可以通过该协议访问。值得注意的是，当有特殊的需求，需要客户端自己采用防崩溃层进行翻译，而不是扩展协议，以保证协议的简单和连贯性。

     g）提炼：抓住问题的本质（主要矛盾），提炼业务的核心领域，围绕核心领域投入重兵，其它的为支撑领域为核心领域提供支撑。业务分析人员、软件设计人员应对核心领域的细节多加关注，这些细节是系统成功的关键。

下一节我们会探讨领域驱动设计的战术建模，敬请期待