中台架构下的 DDD 和落地实践

Why DDD matters?

GoF Design Pattern、EIP、Refactoring、P of EAA 等，它们的理念是通过技术手段解决技术问题，并没有根本上解决业务的问题。

DDD 是真正解决业务问题的架构思想：

• 业务和技术解耦控制软件的复杂性避免业务逻辑的复杂度与技术实现的复杂度混淆在一起，因为他们变化的维度不同把业务逻辑集中到 domain 一层，使得产品和研发能有一个共同的代码交流场所

• 统一并一致的领域建模和代码实现分析模型和设计模型不再割裂以领域为核心的分层架构，技术手段通过倒置依赖进行隔离

• 改变过去Service + 数据库技术驱动开发模式回归业务本质，代码有更强的业务表达能力沉淀出反映领域知识并聚集于关键概念的模型解放研发生产力，不再束手束脚，可以充分发挥面向对象的优势写业务代码

• 统一语言，代码的业务表达能力高

Domain Driven Design (DDD) is about mapping business domain concepts into software artifacts.

为什么 DDD 难落地？

由于 DDD 不是一套框架，而是一种架构思想，所以在代码层面缺乏了足够的约束，导致 DDD 在实际应用中上手门槛很高，理解上容易产生偏差。

有人戏称 DDD 是"阳春白雪"。

• 框架易学，思想难学

• DDD 的最佳实践太少，没有标准在实践落地过程中，会发现很多空白需要自己摸索解决，但又不知道是否合理

• DDD 中出现了很多的概念和术语

• DDD 需要我们在领域建模花费很多的时间和精力

中台特色的 DDD

在中台场景下，仅靠 DDD 是不够的，需要针对中台的特色进行架构补充。

除了 DDD 解决的业务模型和分层架构外，还需要解决：

• 扩展机制业务逻辑扩展业务模型扩展业务流程扩展

• 业务的多态

• 前中台业务解耦，隔离机制

• 能力的上浮和下沉机制

Why framework matters?

If every developer is allowed to implement their own architecture, you can easily end up with lots of optimised but fragmented ideas in the code base. Over time this becomes unmaintainable. It is better to have guidance and direction on how the software should be built into a single defined vision.

There should be one-- and preferably only one --obvious way to do it.

业务开发框架现状

市场上有很多技术框架，也有一些low code甚至codeless框架来满足简单业务场景，但开源的解决复杂业务场景问题的业务开发框架，目前是空白。

中台架构，更多停留在思想和方法论上，具体在代码层面如何落地，目前是空白。

DDDplus，一套轻量级业务中台开发框架，填补了这些空白。

DDDplus

• 以 DDD 架构思想为本，面向复杂业务场景架构设计通过代码框架提供足够约束，让 DDD 不再仅停留在思想层面降低 DDD 上手门槛，为研发减负，防止落地偏差降低复杂度，持续保障业务资产的可沉淀可传承提供dddplus-archetype，自动生成包含最佳实践的工程脚手架

• 14 个核心业务抽象(常用的 9 个)，勾勒出业务中台骨架中台架构的顶层设计以不变应万变研发填空式开发

• 全方位解决业务的不确定性业务逻辑、流程、逻辑模型、数据模型的扩展、多态体系框架本身支持再次扩展扩展业务包支持不重启热更新

• 支撑中台战略的复杂生态协作前台、中台解耦业务隔离 InnerSource 协同机制

• 完整的解决方案业务能力演化，业务测试，最佳实践，架构持续防腐，重构的导流验证，绞杀者落地方案等提供一套完整的Demo工程，手把手真实场景教学