使用 tplant 快速概览代码的领域模型

接地气的 DDD

看到技术雷达发表的《使用函数式语言建立领域模型》文章，非常开心，因为它使用了 TypeScript 来做落地说明，这是一个非常接地气的 DDD。

有不接地气的 DDD 吗？参考《领域驱动设计》这本书和相关（主观的）评价：

为什么说《使用函数式语言建立领域模型》就非常接地气了呢？因为采用了 TypeScript。TypeScript 是 JavaScript 语言的超集，既有 JavaScript 所有的好处，又避免了 JavaScript 饱受诟病的动态类型带来的问题。JavaScript 是很强大的，借浏览器这个宿主打遍天下无敌手，又借 NodeJs 渗透到服务器端。如果一定要纠结学习编程从哪门语言开始的话，那么当然是从学习 JavaScript 开始，没有第二种更好的选择。

TypeScript  基于 JavaScript 构建了类型系统，而《使用函数式语言建立领域模型》则很好地演示了如何通过 TypeScript 的类型系统来设计领域模型。就是说，通过 TypeScript 的类型系统，实现了代码和领域模型的等价，不仅能够用它在敏捷开发过程中进行沟通，而且保证跑着的系统真的就是使用了这样的领域模型，也就是说，把领域驱动设计落了地。

如果只设计，不落地，那其实就是在吹牛嘛，不能当真的。多少团队画出的设计图和实际代码天差地别的？我想有经验的程序员心理都清楚。

很多人倾向所谓的设计先行，写代码前先写设计文档，画图。这里隐含的意思是，代码是实现，而不是设计。但是《使用函数式语言建立领域模型》纠正了这一观点：代码才是设计。

代码=设计=模型=文档

实际上代码比较擅长表达设计内容，从本质上讲，源代码是一个文档，可以完美地描述产品的每个当前设计决策。

《使用函数式语言建立领域模型》

代码才是真正的设计，其他只是 PPT。但是《使用函数式语言建立领域模型》也说了，虽然代码是设计，但是领域专家可不一定能读懂代码（虽然 TypeScript 的语法简单易学，但是我估计多数领域专家甚至某些 Java 程序员，是从本能上排斥的），这制约了代码=模型这样的等式，存在鸿沟。这也是为什么统一建模语言（UML）大行其道的原因，它是一门表达软件产品的图形化语言。

既然 UML 是沟通利器，然而容易和代码脱节，正如作者说的：

我还记得我的第一份工作，每当有代码或者设计改动时，都要去更新UML类图以及数据库设计文档。这些文档大概充当着共享模型的作用，但是最终这些设计类图和文档都慢慢变得不可信，因为没有任何手段保证文档会被及时更新。《使用函数式语言建立领域模型》

UML 是一种视图。就像任何编程语言，其实本质上只是二进制指令的一种高级视图。既然最终运行的软件跑的是二进制指令，而我们可以用高级语言去查看，那么同样我们也可以把源代码以一种图形化的方式去查看。也就是说，将人工绘制 UML 图，变成自动生成，那么就不存在代码和 UML 图脱节的问题了。想用 UML 视图查看源代码哪个版本，就基于该版本生成一份 UML 图就好。

tplant

如果我们使用 TypeScript 来做开发，那么已经有开源工具可以自动从 TypeScript 代码生成 UML 图了，这个工具就是本人参与开发的 tplant！

使用录屏

文字版使用说明

npm install --global tplant
cd your-typescript-project-folder
tplant --input src/**/*.ts --output output.svg
open output.svg

尽管《使用函数式语言建立领域模型》使用了 TypeScript 将 DDD 落地，但是在和不愿意看代码的人之间仍然存在沟通鸿沟。本文厚着脸皮推荐了自己参与开发的一个开源工具 tplant，将 TypeScript 自动转成 UML，弥补了《使用函数式语言建立领域模型》唯一的缺憾。

如果有人说连 UML 都不愿意看，说只想看 PPT，那么请他自行开发一个将代码转成 PPT 的工具吧。总之，不要相信 PPT，一切文档都应该基于代码生成。