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

Why DDD matters?

Note: 本文只讨论DDD的战术层面，BC/ContextMap等战略层面不在本文范围内。

目标场景：你已经明确了要建设XXX中心，如何使用DDD把它建好的问题。

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

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

• 把业务设计和业务开发统一，产品同学和研发同学统一
  • 统一在domain层，DDD的精华在这一层
  • 业务专家角色，在互联网领域大部分是缺失的，实际上是谁更懂谁就专家
• 业务和技术解耦
  • 本质上，DDD是把技术从业务中剥离：让业务成为中心，技术成为附属品
    • 技术是为业务服务的
    • 业务是业务，技术是技术，不要搅在一起
    • domain层，是业务核心：不要把业务模型和规则逃逸、泄露到其他层
    • 以领域为核心的分层架构，技术手段通过倒置依赖进行隔离
  • 是面向业务的设计和编程，不是面向数据库的编程，也不是面向技术实现的编程
  • 客观上起到了控制软件复杂度的作用
    • 避免业务逻辑的复杂度与技术实现的复杂度混淆在一起，因为他们的变化维度和关注点不同
  • 把业务逻辑集中到domain一层，使得产品和研发能有一个共同的代码交流场所
    • UL落地到这一层
    • 前提是代码的业务表达力
• 统一并一致的领域建模和代码实现
  • 分析模型和设计模型不再割裂</