业务中台与领域驱动架构设计

Posted 2021-04-23 数据中台知行合一

摘要：领域驱动架构设计，和业务中台建设乃至微服务架构联系更为紧密些，写在这里，似乎和本公号定位为数据中台有所出入，思考了一下，数据中台的建设，各种建模，其实用的也是领域驱动架构设计，所以也就没有什么不妥了。本文将从领域驱动架构设计的基础理论、最新研究进展、专家学者、实验案例、相关领域展开，从一个全局性的视角对领域驱动架构设计进行审视，将日常所学摘要进行整理汇总。

一、基础理论

1、什么是领域模型驱动设计？

领域驱动设计是一种思维方式，也是一组优先任务，是针对复杂系统设计的一套软件工程方法。分为领域分析建模、领域设计建模与领域实现建模三个过程。

2、领域驱动设计一般分为两个阶段

（1）战略阶段。该阶段从问题域和架构方面进行考量。

针对问题域。通常先进行需求调研，收集领域知识，用例设计，引入限界上下文（Bounded Context）和上下文映射（Context Map）对问题域进行合理的分解，识别出核心领域（Core Domain）与子领域（SubDomain），并确定领域的边界以及它们之间的关系，维持模型的完整性。

架构方面。通过分层架构来隔离关注点，尤其是将领域实现独立出来，能够更利于领域模型的单一性与稳定性；引入六边形架构可以清晰地表达领域与技术基础设施的边界；CQRS 模式则分离了查询场景和命令场景，针对不同场景选择使用同步或异步操作，来提高架构的低延迟性与高并发能力。在对传统MVC架构系统进行改造时，一般分为接口层、应用层、领域层、基础设施层。

（2）战术阶段。

在战术层面，它主要应对的是领域的复杂性。领域驱动设计用以表示模型的主要要素包括如下：

实体（Entity）。一个由它的标识定义的对象叫做实体。通常实体具备唯一id，能够被持久化，具有业务逻辑，对应现实世界业务对象。

值对象（Value Object）。描述事物的对象；更准确的说，一个没有标识符描述一个领域方面的对象。这些对象是用来表示临时的事物，或者可以认为值对象是实体的属性，这些属性没有特性标识但同时表达了领域中某类含义的概念。通常值对象不具有唯一id，由对象的属性描述，可以用来传递参数或对实体进行补充描述。

聚合及聚合根(aggregate、aggregate root)。聚合是用来定义领域对象所有权和边界的领域模式。聚合定义了一组具有内聚关系的相关对象的集合，我们把聚合看作是一个修改数据的单元。 一个聚合是一组相关的被视为整体的对象。每个聚合都有一个根对象（聚合根实体），从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用，但是外部对象只能引用根对象实体。只有聚合根才能使用仓储库直接查询，其它的只能通过相关的聚合访问。如果根实体被删除，聚合内部的其它对象也将被删除。

领域事件（Domain Event）。程序事件通常分为：系统事件、应用事件和领域事件。领域事件的触发点在领域模型中。它的作用是将领域对象从对repository或service的依赖中解脱出来，避免让领域对象对这些设施产生直接依赖。它的做法就是当领域对象的业务方法需要依赖到这些对象时就发出一个事件，这个事件会被相应的对象监听到并做出处理。譬如跨限界上下文时，使用关键应用事件触发事件传递。

资源库（Repository）。仓储（资源库）是用来管理实体的集合。仓储里面存放的对象一定是聚合，原因是domain是以聚合的概念来划分边界的；聚合作为一个整体概念，要么一起被取出来，要么一起被删除。

工厂（Factory）。工厂用来封装创建一个复杂对象尤其是聚合时所需的知识，作用是将创建对象的细节隐藏起来。客户传递给工厂一些简单的参数，然后工厂可以在内部创建出一个复杂的领域对象然后返回给客户。当创建实体和值对象复杂时建议使用工厂模式。

服务（services）。服务提供的操作是它提供给使用它的客户端，并突出领域对象的关系。所有的service只负责协调并委派业务逻辑给领域对象进行处理，其本身并未真正实现业务逻辑，绝大部分的业务逻辑都由领域对象承载和实现了。service可与多种组件进行交互，这些组件包括：其他的service、领域对象和repository 或 dao。其又细分为领域服务和应用服务。

应用服务（Application Service）。应用程序服务构成应用程序或服务层。

领域服务（Domain Service）。领域服务封装了一些域概念，这些概念并不是自然建模的。领域服务是无状态的，须以非常干净简洁的代码实现。

通常战略阶段和战术阶段要求领域专家和开发团队紧密配合，沟通协调完成，示意图如下：

总结下埃里克埃文斯对战术设计之间的关系：

3、领域架构设计

我们来看一个领域架构设计的全景图：

领域驱动设计过程如下：

4、领域驱动设计的原则

4.1、注重实践。模型需要代码。 

4.2、专注于具体场景。抽象思维需要落地于具体案例。 

4.3、不要试图对任何事情都进行领域驱动设计。画一张范围表，然后决定哪些应该进行领域驱动设计，哪些不用。不要担心边界之外的事情。 

4.4、不停地实验，期望能产生错误。模型是一个创造性的流程。 

5.5、DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。

二、最新研究进展

1、领域驱动设计是我们应该专注于用户所关心领域里的重要问题的指导原则。我们的智慧应该用在理解这一领域上，和那个领域的其他专家一起将它抽象成一个概念。这样，我们就可以应用这个抽象出来的概念构造强大而灵活的软件。

2、大趋势是软件会应用于越来越复杂的问题，越来越趋近于业务的核心，普通的MVC架构难以应对大型复杂业务。

3、更多前沿的话题发生在域描述语言（DSL）领域，我一直深信DSL会是领域驱动设计发展的下一大步。

4、微服务成就了领域驱动设计，领域驱动设计成就了微服务。

5、以函数式编程思想为基础的领域建模理念与事件驱动架构和响应式编程的结合，可能在低延迟高并发的项目中发挥作用。

6、以 DDD 设计方法为基础的框架的出现，让微服务设计与领域建模变得更加容易，降低领域驱动设计的门槛。

三、专家学者

1、[美]埃里克 埃文斯（eric evans）。领域驱动设计之父，世界杰出软件建模专家。他创建了Domain Language公司，致力于帮助公司机构创建与业务紧密相关的软件。他在世界各地宣讲领域驱动设计（Domain-Driven Design，DDD）的思想，开设课程，参加会议，接受专访，拥有大批的追随者。从20世纪80年代开始，他就以设计师和程序员的双重身份参与过许多大型面向对象系统的设计和开发，涉及各种复杂的业务和技术领域。同时，他还培训和指导过许多开发团队开展极限编程实践。

2、弗农（Vaughn Vernon）是一个经验丰富的软件工匠，在软件设计、开发和架构方面拥有超过25年的从业经验。他提倡通过创新来简化软件的设计和实现。从20世纪80年代开始，他便开始使用面向对象语言进行编程；在20世纪90年代早期，他便在领域建模中应用了领域驱动设计，那时他使用的是Smalltalk语言。他在很多业务领域都有从业经验，包括航空、环境、地理、保险、医学和电信等领域。同时，Vaughn在技术上也取得了很大的成功，包括开发可重用的框架和类库等。

3、张群辉，阿里盒马架构总监。10 多年技术及管理实战经验，前阿里基础机构事业部工程效率总监，长期在一线指导大型复杂系统的架构设计。DevOps、微服务架构及领域驱动设计国内最早的实践者一员。崇尚实践出真知，一直奋斗在技术一线。

4、张逸。ThoughtWorks咨询师，著有《软件设计精要与模式》，译有《恰如其分的软件架构》 等书。

四、实验案例

1、阿里盒马领域驱动设计实践。

2、领域驱动设计在美团点评业务系统的实践。

3、领域驱动设计旅游电商的实践。

五、相关领域

1、业务中台。

2、scrum敏捷开发。

3、微服务架构。

4、XP极限编程。

以上，是对领域驱动架构设计的一个整体感知，后续文章将会深化说明战术设计如何演进，并使用一个交管业务场景进行案例说明，同时辅以源码进行讲解。