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工程，手把手真实场景教学
