如何将微服务与领域驱动设计有效融合并成功实施？

本文共计8052个文字，预计阅读时间需要33分钟。

为什么选择DDD+面向对象设计，以数据行为为绑定，告别贫血模型+降低复杂性，分而治之+优先考虑领域模型，而不是切割数据和行为+准确传达业务规则，业务优先+代码即设计+它通过边界划分？

为什么要用DDD

• 面向对象设计，数据行为绑定，告别贫血模型
• 降低复杂度，分而治之
• 优先考虑领域模型，而不是切割数据和行为
• 准确传达业务规则，业务优先
• 代码即设计
• 它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现业务和技术统一的架构演进
• 领域知识共享，提升协助效率
• 增加可维护性和可读性，延长软件生命周期
• 中台化的基石
• ...

领域驱动设计的作用

说到 DDD，绕不开 MVC，在 MVC 三层架构中，我们进行功能开发的之前，拿到需求，解读需求。往往最先做的一步就是先设计表结构，在逐层设计上层 dao，service，controller。对于产品或者用户的需求都做了一层自我理解的转化。用户需求在被提出之后经过这么多层的转化后，特别是研发需求在数据库结构这一层转化后，将业务以主观臆断行为进行了转化。一旦业务边界划分模糊，考虑不全，大量的逻辑补充堆积到了代码层实现，变得越来越难维护。

假如我们现在要做一个电商订单下单的需求，涉及到用户选定商品，下订单、支付订单、对用户下单时的订单发货：

MVC 架构：我们常见的做法是在分析好业务需求之后，就开始设计表结构了，订单表，支付表，商品表等等。然后编写业务逻辑。