“领域驱动设计”答疑（六）

DDD

问题：当前开始流行的“低码化”或者“无码化”开发，算是MDA（Model-Driven Architecture）的再次兴起吗？无码或者低码化开发和领域驱动设计有关系吗？

回答：MDA不存在再次兴起，它一直都在合适的领域使用着，只是当年人们对它报的期望过高了。目前市场上大多号称“低码化”或者“无码化”的软件产品或服务，目标是为了降低客户的定制或者二次开发成本，有着明确的市场目的，和领取驱动设计没有直接关系。

---

这两年很多公司号称提供”低码化“和”无码化“的软件产品或者服务，这些产品集中在基于云服务的看板系统、OA（Office Automation）或者CRM（Customer Relation Management）等SaaS服务领域。

类似系统如今能以“低码”或“无码”的方式配置开发，主要是因为近些年云服务、后端微服务架构、前端组件化技术趋于成熟，一个包含前后端的完整子功能比以前更容易组件化。通过将系统拆解成一个个独立组件，通过搭积木式的配置组装方式提供给客户，可以将定制成本转移给客户，让产品提供方基于配置组装接口快速标准化。

这种设计在商业上是否可行，取决于系统或服务给客户带来的价值能否盖过转移给客户的成本。“低码”或者“无码”的目的是让客户的配置或再开发的成本和技术门槛尽可能的低，落在客户的可接受范围内。

回到技术角度，“低码”或者“无码”化开发是代表先进生产力的。我们前文介绍过MDA的目的就是标准化从模型到代码的自动生成，使得设计人员可以聚焦于模型的设计和演进上，然后从模型直接生成代码，降低软件的开发和维护成本。

但是前文也说了，MDA比较适合业务相对稳定且实现技术比较标准化的软件类型。而且要注意的是，即使软件的特点适合采用MDA，对于代码自动生成这件事还是要时刻保持理性。

不用写代码就能实现软件这件事一直都极具蛊惑力，常见的一种想法是开发人员只用画图，最终从模型图生成代码。

我们前文说了，用画图来完全替代代码开发，会有以下问题：

1）大部分情况下，模型图很难表达所有的实现语义。所以自动生成的代码是不完备的，还需要人工修改代码以补充缺失的实现细节；

2）针对图的编辑、重用，重构、版本管理，往往不如直接搞代码来的高效；

3）每当模型变化后，从模型图重新生成的代码又要和已实现代码进行merge，合并成本大，效率低；

图形化的方式适合提供给某些有特定需要的客户，或者作为某种可视化的辅助手段。面向开发人员，最好设计一种文本化的模型描述方式。简单的话可以使用某种配置文件（YAML或TOML等），或是专门设计一种DSL（领域特定语言）。

模型的配置文件或者DSL描述，可以用于运行时加载，也可以用于代码生成，或者两者皆用。如果做代码生成的话，需要确保生成的代码最好是相对稳定且物理上独立的，每次重新生成后可以直接替换，避免和手写的代码频繁merge。

另外，代码生成的话还需考虑生成的代码是否入库。如果入库，则需要保证库中生成的代码和模型描述文件在必要的时候是同步的，这需要某种机制保证。如果生成的代码不入库的话，则需要在每次构建前先做代码生成，这时需要注意生成的代码可能跳过了某些流水线环节，例如安全性检查，需要仔细评估这是否是可以的。

我们知道DSL分为内部DSL和外部DSL（参见《领域特定语言》）。如果用内部DSL来描述模型，工具链可以借用宿主语言的，只需要专注于DSL的易用性和可调可测设计上。如果是用配置文件或者外部DSL描述模型，就必须为工具链做额外的设计和开发。如果手动编写麻烦，出错时缺乏足够的提示信息，DSL也会变成效率的瓶颈，因此设计和开发各种好用的辅助工具是必不可少的。

最后，使用外部DSL，要抵制住“图灵完备”的诱惑。外部DSL最好只做声明式表达，尽量不要掺杂进复杂的逻辑，否则使用门槛和工具链的开发成本就会极剧上升，一些情况下会变得还不如直接写代码。

如上，顺便回答了“通过模型做代码生成，有哪些注意事项？。

---

《“领域驱动设计”答疑（汇总）》