云原生时代，领域驱动设计思想（DDD）如何落地？

随着数字化世界的持续演进，软件架构设计思想在碰撞中不断优化。云原生时代的到来，加速了行业对于领域驱动设计理念（Domain-Driven Design）的实践落地诉求。

在刚刚结束的DDDChina2021领域驱动设计峰会上，华为云数据建模架构师凌云分享了自己对领域驱动设计理念的理解和实践。

软件架构的演进

近些年随着经济和科技的迅猛发展，各行各业或多或少都有软件系统的应用，电商、银行等行业的迅速发展带来的业务复杂度提升、访问并发量提高，都对软件的可靠性、稳定性提出了更高的要求。因此软件架构在近些年经历了从单体架构、到分布式架构、再到目前比较主流的微服务架构，以及逐渐兴起的Serverless架构的演进过程。

什么是领域驱动设计思想（DDD）呢？

DDD的全称为Domain-Driven Design，即领域驱动设计，是在一定领域内，发现问题，抽象共性不变的流程，进而提供问题解决方案的过程。它的方法是通过一个统一语言领域建模、领域划分等一系列手段来降低复杂度，并基于面向对象分析（OOP）技术进行了分层规划，对软件开发全生命周期使用语言进行统一，并强调业务与技术相结合的一种过程。

-为什么要建模？

建模通过可视化的模型，让懂业务的人和懂技术的人可以互相交流沟通。同时，我们做了一个模型之后可以很方便的复用传播，在其它项目中进行改造，最后还可以对做出的决策进行文档化。

-什么是“领域”模型？

领域的逻辑就是显性的专业知识。比如现在需要开发一款法务人员使用的软件系统，那么就会存在这样的问题：法务人员不懂软件开发，开发人员不懂法律条文信息，而在开发过程中二者又需要进行不断的沟通和确认，法律领域的模型就是连接二者的一个桥梁，领域模型主要倾向于将领域的知识给描述出来，管理合规性。

-领域建模和软件架构的关系

DDD如何落地

下面通过一个具体的数据建模软件的案例来给大家说明一下如何落地DDD。

以一款数据建模软件开发为例，逻辑模型和物理模型如下图：

逻辑模型

物理模型

我们可以通过如下步骤实现DDD的落地：

1. 与领域专家交流

   与领域专家交流是整个流程的重中之重，在该过程中业务建模人员需要对概念、操作、行为、约束等较为熟悉，因此，领域建模的第一步，是明确业务边界，将系统的所有行为收缩到可视化建模子领域以内。其次需要理解数据变化的逻辑，在可视化建模的概念-逻辑-物理正向设计过程中，概念驱动逻辑，逻辑驱动物理，针对不同角色的用户，所关注的阶段并不同。从业务角度看，实体变更将驱动表变化；从用户角度看，业务逻辑变更要求系统演变适配。最后与领域专家验证需求，正向推送逻辑：实体变更审核通过，则驱动对应表发生变化。此变化在物理模型上，开发者应根据表的变更，修改软件系统的实现。

2. 实现对应的领域模型

   合理规划业务对象的关系、继承，实体包含属性、表包含字段、表包含索引、关系关联两个实体、ER图包含实体、关系等。确定聚合关系，实体头信息和属性列表构成实体、表头信息和字段列表+索引列表构成表、版本状态与流程构成版本化。接下来需要确定值对象，如字段类型、索引类型、操作动作类型等，最后领域模型验证需求，通过以上的流程我们实现了一个领域模型，如下图：

   

    

   根据建立的领域模型，把通用部分抽象出来，相应的UML图也进行了一些修改，领域模型就已经创建完成了。
3. 设计原型界面和交互逻辑

   实现对应的一个领域模型，接下来设计原型界面和交互逻辑，交互逻辑可以理解为这个领域模型的各种事件、事件驱动。

4. 领域模型自动生成结构框架代码

   通过领域模型构建的UML图可直接生成项目框架代码，在框架代码中会生成相应的实体类，以及各种事件也生成了相应的event代码。

   

   UML图自动生成框架代码

   
5. 在框架中进行细化和优化

   代码框架可以直接使用，如果还需要扩展其它的内容，比如除了增删改以外，还希望具有查询历史版本的功能，这种event在领域图上难以表达，或者是表达了之后生成的也不一定准确，所以这种情况的代码需要软件开发者来编写。但是已经不需要再关注那些框架性的接口或者服务层的问题了，只需要在相应的地方，对特性能力进行增强即可。

   

   通过以上步骤完成的建模软件系统落地， 既能自动生成代码又能做好看护，保持架构与DDD模型的一致性。

   通过以上讲解，您对领域驱动设计（DDD）理念有初步的了解了吗？任何理念的应用都需要深入的体会和反复的实践，希望本文能给大家一些启发和帮助。