DDD下的代码文档生成

一、背景

目前低代码生成领域非常火爆，而且市场价值在逐步上升，很多巨头都在重金投入。低代码的出现意味着程序员可以从大量重复低效的劳动中脱离出来，同时可以更好更快的支持业务解决实际问题，极大的提高了交付价值的效率。那么在DDD中实际上也有一些人尝试使用低代码的方式进行建模，意图将建模过程程序化，自动化，通过模板或者预设脚本得到建模结果。本章内容则重点讨论DDD下的代码文档生成的意义，以及这种思路将带给我们什么启示。

二、观点

2.1 观点1–手动构建

很多研究DDD的人都会遇到这个问题–是否使用低代码来降低建模成本。有些资深大佬已经在这个问题上做了一些探索，但是效果并不好，另外一方面在进行建模的时候如果已经通过有效的方式进行建模的话那么手动构建则是最优选项。
究其原因则是DDD在建模过程中是动态调整的，建模产物也不是一成不变的。建模出来的衍生物（模型，数据库表，接口文档）也只是在某一阶段能表达业务语义。在长时间的迭代过程中通过程序化构建的产物则显得有点鸡肋。主要表现为模型陈旧，api固化导致的改动成本增加。
最后的自动化构建问题来自于对服务，工程的挑战，由于实体模型的不断变化，领域在业务迭代的变化导致工程包，模块，接口等都处于动态迭代中。最直接的表现就是重构会随时发生，那么代码生成很快会跟不上这种节奏。强行根据数据库模型或者实体模型进行自动化构建所得到的产物对当前需求来说可能并不能像第一次构建那样高效，同时这也慢慢偏离了DDD文档构建的初心。所以很多大佬比较支持手动构建模型，在这个过程中领域专家，产品，程序员都可以从中获得业务更深层次的信息。

2.2 观点2–借助代码生成

在低代码领域很多人都有过一些尝试，包括我，而且还因此得过季度奖金。但是在DDD领域进行低代码尝试对于大多数开发者来还是很有挑战的，毕竟重复的劳动需要工程化。借助低代码平台融合DDD的理论其实也不是很难。针对DDD的核心概念进行领域，子领域，上下文等的构建解决了上手DDD的难度。
在DDD代码生成这里有个大佬已经身体力行的做了一些事情，就是Martin Fowler大神的著作《领域特定语言》。这本书从领域出发来阐述如何做一个基于DDD和通用语言的代码生成工具。比较现实的是实现成本还是很高的。大多数情况下我们达不到大佬的水准。
当然，这不意味着DDD的代码文档生成就解决不了，ContextMapper的整个解决方案基于Java 工具类和插件模式来做代码生成，核心策略就是基于上下文图模式做领域模型，实体模型的构建。另外还有很多其他大牛在探索基于DDD的代码文档生成，但是目前看来还有很长一段路走才能更加成熟。

三、代码生成产品

3.1 UBML

https://gitee.com/ubml/ubml-impl

3.2 ContextMapper

https://developer.aliyun.com/article/771374?utm_content=g_1000251254

3.3 携程契约系统

https://mp.weixin.qq.com/s/4suazm8Z3dheq9jO9g0bjQ

3.4 COLA

这里简单介绍一下COLA 代码生成是基于整个项目骨架的，只生成DDD相关的包结构，至于建模还是需要其他方式。

四、DDD下的低代码意味着什么

这里我通过携程的契约系统作为引子来阐述DDD下的低代码可以为我们带来什么，这种低代码与一般的低代码产出的内容是不一样的，这里产出的是领域模型，领域文档，相关领域图，从业务角度出发而沉淀出的内容。

4.1 工程提效

通过DDD的低代码产出的模型可以复用共享，同时更高维度的领域上下文，子领域，上下文图也都非常清晰。在开发业务前端系统，中后台系统都可以对领域对象中的字段，模型，数据流进行追溯。新需求在融合已有系统中会更加便捷，当我们面临与领域，模型相关的需求变更时我们可以更容易也更快地做一些调整。这些都基于我们已经将不同业务线的业务领域和通用的业务领域都摸清了，有沉淀的文档，领域模型，而且是可视化的，可追溯的。
很多时候模型复用并不代表领域服务可以复用，如果一个领域内有很多微服务在支持，同时这些微服务都有自己的数据库。而在业务发展，服务迭代的过程中很多服务慢慢都变得僵化，没有流量。如果没有建立服务画像的话这些服务依然是一种比较鸡肋的存在。从领域的角度来说这是不是意味着我们的领域不够精简，我们的服务是不是只能拆分不能合并，是不是无法形成领域内的服务能力。
这里再回头看携程的契约系统，这个系统从模型的角度出发很明显的在DDD下的代码文档生成走出了第一步，而且有了一些原始业务模型数据的积累。

4.2 资产构建

上面说了DDD下的低代码可以对工程提效，那从更长远和更深层次的角度考虑一下，当我们有了这些领域模型，领域上下文关系，我们是不是可以对数据库模型进行梳理，是不是可以建立大数据的元数据积累，基于这些模型我们可以很快地建立起数据中心的能力，同时基于数据资产做数据分析更好的辅助业务发展。

4.3 业务扩展

在业务扩展方面，这里主要说明的是我们在DDD下的低代码可以帮助业务发展过程中一直站在领域的角度去考虑问题。在已有领域模型和文档的情况下业务扩展和调整都有理可依。在迭代开发的时候我们可能会遇到一些下面的问题：

1. 上游加个字段对下游是否有影响，需要下游支持怎么办
2. 上游多个客户端要接入下游存在模型冲突怎么办
3. 新需求进来是单拉一个库还是单拉一个服务
4. 在团队合作开发的时候这个功能点，模块在你这边实现合适还是我这边实现合适
5. 领域内的模型需要扩展支持更多业务功能需要怎么兼容当前业务

这些都是经常遇到的问题，更直接的解决方法就是我不管什么领域，什么模型，来个需求我就评估下改动点，工作量，上下游接口。但是我们大多数的时候并没有从领域层面去关注这些细节带来的改变，从而不能有计划有针对性的去梳理整个业务流程，领域服务和模型。

4.4 总结

关于DDD下的低代码探索实际上可能不是那么有趣，但是我们依然可以得到很多经验。

我这边今年已经完成了DDD整个概念和实战体系相关的内容，如果想要了解更多请关注公众号：