上两个章节，针对低代码的常见应用做了一个介绍，从功能上各家平台大同小异，也有很多专注于某一个方向上的开源应用实现的质量也很高。单作为一款专业的低代码平台而言，其核心点还是要立足于扎实的理论基础和底层技术。后续的几个章节我们会更多的关注低代码平台一些模型理论和支撑技术，有一些概念可能会晦涩一些。

一，DDD(领域驱动模型)

（1）DDD简介

市面上常见的低代码平台几乎都会无一例外的在自己的产品特性的加上一段，DDD模型支持的描述。DDD不是一个新的概念，其从理论提出（2004年首发）到现在将近20年的发展史，相对而言一致不温不火但知道最近几年随着云计算、数据中台等技术的快速发展。DDD得到了快速的发展，特别是近一两年低代码技术的火热。DDD模型几乎霸屏了各大厂商的技术交流PPT。

（2）低代码平台为啥那么会青睐DDD？

详细的（DDD）技术理论模型就不展开来描述了，网上的资料丰富且专业。我们重点还是放在低代码平台为什么会青睐DDD ？

低代码平台从一出生便有3个标签: 可视、速成、快发.

1，可视化：拖拽式组件可在组件库中，快速而有效的组合业务。

2，速成：高度集成组件提升了组合速度同时隐藏了更多的技术细节，方便非技术人员的参与部分平台甚至将人人可编程作为卖点。

3，快发：高度封装的业务组件会增加许多的根据哥哥行业不同私有的技术特点及技术属性，通用的软件开发流程在一定程度就很难以满足其独特的需求。通常厂商会配发相应的自由的从代码管理、程序打包、系统上线、以及运维维护。但这一特点同时也产生一个独特的 devops（自动化运维）特性。在平台上通常会描述会，协同开发，在线开发、一键发布。自动运维等功能。

在以这三个标签为“指导思想”的驱动下，各种业务（“OA”,"ERP"，“CRM”）应用模型，快速的模板化组件化。但软件功能（组件）的本质是业务本身的特性。而业务本身是极其复杂的，低代码降低了代码的编辑难度，但其本身的复杂过程并没有被简化，只是换了一种形式。为了应付这种变化，多数低代码平台在业务的组合特性上更多了附加了一些更为偏向与传统技术的所谓的技术组件来应对变革，比如：让传统的业务组件在其业务属性上增加了，一些可视化编辑的注入，”点击事件“” ，点击后可以调用某某方法，根据会回参在判断执行那些业务展现。这一些类的扩展和改变确实增加了系统的可用性，但直接照成的问题是业务的技术实现变得更加臃肿。而且由于技术实现外延的无限扩充，也使得其在可视化方面易用性降低，培训使用单独加大，部署发布细节增加等等问题。

平台陷入焦灼状态，离我们的初衷越来越远的时候，陷入深度思考，要实现业务灵活性，功能就必须越来越强大而且提供更多的原生支持，而功能的强大随之而来的就是新的复杂度，这些是严重背离低代的设计思想和初衷的。

随着业务的深入，越来越多的平台开始进入新的思考？

拖拽就是低代码吗？

代码的本质是为了业务描述，其可视化只是简单的改变了其构建方式，而代码所表示的逻辑任然是程序员去完成，而对于程序员而言，拖拽也未必就是更好的代码书写方式。

组件化是业务抽象最好的解决方案吗？

组件化也许也只是我们自身经验的复制和总结，其不具备可复制性。具体的业务需要的不是功能完备的组件。每一种组件只能覆盖特定的业务。而在扩展到其他领域时其更大可能性是能集成一种抽象的方法然后重新构建。而不是复用原来的组件。

也许我们的出发点错了，低代码平台的目的不是简化代码，降低复杂度以便于让更多的人来写代码，代码的目的是业务的高度抽象。其真正的内涵是通过书写代码的方式将具体的业务以特定的方式固定下来。通过拖拽或者配置生成代码其实只是一种简单的COPY，并不能将其业务的内涵传递给开发者，这其实也是很多低代开发者只要一遇到变化就无所适从，非常迷茫的地方，因为要真正改变还是需要深入到代码细节中才能窥知一二。

也许我们抽象的方式错了，我们不应该单一的从业务上来抽象。然后还用传统代码去实现，我们应该统一起来考虑，将业务技术（代码）共同抽象，创建一种统一的方法模型，在遇到问题或变化时能用一种统一的方式去思考统一考虑。

DDD给了低代码从业者一个新的思考角度！

（1） 统一技术实现语言（一种更适合低代的语言方案）

（2） 领域模型（从业务模型入手更贴近业务的模型根系构建方式）

（3）DSL 特定领域表达式（这个是代码但其推崇的时用最少的代码实现最强的业务）

篇幅限制问题，抽象和主管描述太多了，后续章节中我们会根据结合具体的实例来描述DDD实现。

章节预告：

(1) 统一语言(JAVA实现) 详解及事例，附具体代码实例。

(2) DDD建模要素及模型代码双向转化，模型混合编译

（3）DSM 特定领域建模实现过程，实战工程

当然最重要的也是各位能，点赞转发！优先获取，DSM实例及开源版本试用。