数字化转型带来的业务变化对传统的理论和架构正在形成巨大的冲击。 。。

传统的运营模式注重效率 ，，，认为商业环境组织有序、、、变化缓慢且相对可预测 ，，，其业务的需求和边界是清晰的 ，，，是可以被准确描述和表达的 ，，，所以传统系统设计遵循企业EA架构中业务需求-业务架构-数据架构-应用架构-技术架构这一严密的逻辑实现路径 ，，，这在业务相对稳定的年代是规范的构建方式 ，，，也是被广泛接受的基于数据库为核心的系统建设范式模式。 。。

然而 ，，，这其中的挑战在于没有办法实现对“不确定性”的支撑！这种不确定性源于业务需求的不明确 ，，，业务边界被打破而导致的模糊化 ，，，以及业务架构的不断变化。 。。

通过一个更形象的例子来解释这种不确定性对于传统EA架构理论的挑战：

我们的企业就好比一个人体组织 ，，，人体组织运行依赖结构、、、动力和控制三个核心要素 ，，，其中结构就类同组织—业务概念模型 ，，，动力就是业务流程 ，，，控制对应业务规则。 。。

可以想象的是 ，，，组织是具有生命力且灵活变化的有机体 ，，，概念模型、、、业务流程和业务规则相互关联。 。。流程对概念模型中所代表的关于事物的知识采取行动 ，，，而这些行动又受制于业务规则。 。。成功的商业行为取决于有效的整合 ，，，这些基本的相互关系必须考虑在内。 。。而当整个有机体发生任何一个局部变化的时候 ，，，传统系统设计中那个最初的也是最为根本的基础业务需求就会出现变化 ，，，如果按照传统的设计理念来应对这些变化 ，，，那几乎就是每一次的推倒重来 ，，，这显然是不可想象且难以接受的。 。。

可组合的业务(Business Composability)已经被Gartner倡导认为是应对业务创新中不确定性的最佳策略和方法 ，，，其核心思想是将具备业务共性的元素沉淀形成组件化、、、模块化 ，，，以便快速的搭建新的应用。 。。Gartner副总裁兼分析师陈勇指出 ，，，一方面 ，，，企业需要有一个方式来应对环境的不确定性；另一方面 ，，，企业也需要把其业务做到更加敏捷。 。。

同时 ，，，Gartner认为可组合业务由组合式思维、、、可组合的业务架构和可组合技术三个部分组成。 。。

可组合的思维 ，，，是最上面的一层。 。。Gartner副总裁分析师Monika Sinha强调：“传统业务思维将变化视为一种风险 ，，，而可组合性思维能够驾驭加速变化的风险 ，，，并且创造出新的业务价值。 。。”数字化时代 ，，，企业架构需要为不确定性和持续的变化而设计。 。。可组合的企业架构不是为了效率而优化 ，，，而是为适应而优化。 。。企业在设计业务的时候 ，，，从理念上面来讲 ，，，就要考虑把这个业务设计成为一个可组合的 ，，，便于未来重新组装 ，，，也可称为“模块内部紧耦合、、、模块之间松耦合” ，，，也就是说 ，，，模块和模块之间耦合的关系是松散的 ，，，这样更便于拆开来；而模块内部耦合是比较紧的、、、形成一块积木。 。。具备可组合性思维的企业机构 ，，，其领导者往往鼓励创建并重复使用模块化的业务能力和技术 ，，，指导企业机构应对不确定性和把握机遇的思维方式。 。。

可组合的业务架构可确保组织具有灵活性和弹性。 。。组合能力相对较高的企业 ，，，往往通过多种不同的方式组合能力、、、产品和服务等业务要素 ，，，从而创造出新的价值。 。。

可组合的技术 ，，，是采用一些适合变化的敏捷方法论 ，，，比较典型适配的就是低代码。 。。可组合技术可以理解为业务需要依靠技术运行 ，，，而技术本身必须具备组合能力才能运行可组合的业务。 。。为此 ，，，企业机构需要将组合能力延伸至整个技术栈 ，，，构建可快速便捷整合的系统和数据 ，，，通过使用API、、、微服务和其他模块化组件 ，，，可将技术能力生成工作进行模块化和自动化处理。 。。

于是 ，，，你会发现 ，，，低代码是天然匹配这三个“可组合的思维”、、、“可组合的业务架构”和“可组合的技术”的核心诉求！

当然 ，，，这种可组合的业务或者说业务组件也不是仅靠低代码就可以实现的 ，，，低代码在这其中仅仅扮演了最后封装的那个角色 ，，，实现可以全面支撑敏捷高效的另外一个条件就是领域建模。 。。所以这里所说的低代码显然不是局限于二维表单的 ，，，而是面向领域建模的以模型驱动为核心的低代码技术！因为 ，，，只有领域驱动设计的领域建模才有可能满足复杂业务场景！

“Domain-Driven Design领域驱动设计”简称DDD ，，，是一套综合软件系统分析和设计的面向对象建模方法 ，，，某种程度上可以理解为这是一种具有颠覆意义的设计思想。 。。过去系统分析和系统设计都是分离的 ，，，这样割裂的结果导致需求分析的结果无法直接进行设计编程 ，，，而能够进行编程运行的代码却扭曲需求 ，，，导致客户运行软件后才发现很多功能不是自己想要的 ，，，而且软件不能快速跟随需求变化。 。。

DDD则打破了这种隔阂 ，，，提出了领域模型概念 ，，，统一了分析和设计编程 ，，，使得软件能够更灵活快速跟随需求变化。 。。DDD其实是研究将包含业务逻辑的语句统一在对象建模的学问 ，，，包括业务流程、、、业务规则、、、规则引擎、、、术语字典、、、DSL或正则表达式、、、商业智能和数据分析等都属于业务逻辑的范畴领域。 。。DDD革命性在于：领域模型准确反映了业务语言 ，，，接触到需求第一步就是考虑领域模型 ，，，而不是将其切割成数据和行为 ，，，然后数据用数据库实现 ，，，行为使用服务实现 ，，，最后造成需求的首肢分离。 。。DDD让你首先考虑的是业务语言 ，，，而不是数据 ，，，重点不同导致编程世界观不同 ，，，甚至可以摆脱数据库设计中三范式模式的局限性。 。。

DDD是解决复杂场景中大型软件的一套行之有效方式 ，，，在国外已经成为主流。 。。DDD认为很多原因造成软件的复杂性 ，，，我们不可能避免这些复杂性 ，，，能做的是对复杂的问题进行控制。 。。而一个好的领域模型是控制复杂问题的关键。 。。如下图所示 ，，，领域模型的价值在于提供一种通用的可视化语言 ，，，使得领域专家、、、产品经理和软件技术人员联系在一起 ，，，沟通无歧义。 。。

当然 ，，，领域模型的核心基础在于对象建模 ，，，由对象组装业务域 ，，，对象内的各个逻辑要素紧耦合 ，，，而对象之间或者域和域之间松耦合。 。。业务流程的抽象和业务功能的拆分针对领域模型为核心的驱动设计以及服务化(微服务)在平台功能抽象拆分提供了相对值得借鉴的思路 ，，，催化了以业务功能细分作为域划分的依据的组件化方案 ，，，主要诉求是在细分的业务功能组件服务基础上 ，，，能按需快速灵活的组合 ，，，从而支撑不同的业务模式 ，，，提供业务敏捷性 ，，，支撑业务创新求变。 。。

由此可见 ，，，新一代的应用建设必然趋势在于通过低代码对业务元素做对象建模并封装 ，，，基于业务规则和业务逻辑组建业务域 ，，，这在保证敏捷开发的同时也对灵活多变的业务创新带来了高效的支撑 ，，，正是所谓的新应用架构的“三驾马车”。 。。