中台架构下的DDD和落地实践
Why DDD matters?
GoF Design Pattern、EIP、Refactoring、P of EAA等，它们的理念是通过技术手段解决技术问题，并没有根本上解决业务的问题。
DDD是真正解决业务问题的架构思想：
业务和技术解耦控制软件的复杂性避免业务逻辑的复杂度与技术实现的复杂度混淆在一起，因为他们变化的维度不同把业务逻辑集中到domain一层，使得产品和研发能有一个共同的代码交流场所
统一并一致的领域建模和代码实现分析模型和设计模型不再割裂以领域为核心的分层架构，技术手段通过倒置依赖进行隔离
改变过去技术驱动开发模式回归业务本质，代码有更强的业务表达能力沉淀出反映领域知识并聚集于关键概念的模型解放研发生产力，不再束手束脚，可以充分发挥面向对象的优势写业务代码
统一语言，代码的业务表达能力高
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.
业务开发框架现状
市场上有很多技术框架，也有一些甚至框架来满足简单业务场景，但开源的解决复杂业务场景问题的业务开发框架，目前是空白。
中台架构，更多停留在思想和方法论上，具体在代码层面如何落地，目前是空白。
DDDplus，一套轻量级业务中台开发框架，填补了这些空白。