一文带你落地DDD

一.前言

hello，everyone，好久不见。最近几周部门有个大版本发布，一直没有抽出时间来写博。由于版本不断迭代，功能越做越复杂，系统的维护与功能迭代越来越困难。前段领导找我说，能不能在架构上动手做做文章，将架构迁移到DDD。哈哈哈哈，当时我听到这个话的时候瞬间来了精神。说实话，从去年开始从大厂的一些朋友那里接触到DDD，自己平时也会时不时的阅读相关的文章与开源项目，但是一直没有机会在实际的工作中实施。正好借着这次机会可以开始实践一下。

本文由于本文的重点为MVC三层架构如何迁移DDD，因此将先对DDD做一个简要的概念介绍(细化的领域概念不做过多展开),然后对于MVC三层架构迁移至DDD作出迁移方案建议。如有不对之处，欢迎指出，共同进步。

本文尤其感谢一下lilpilot在DDD落地方案上给出的宝贵建议。

DDD系列博客

1. 一文带你落地DDD
2. DDD落地之事件驱动模型
3. DDD落地之仓储
4. DDD落地之架构分层

二.DDD是什么

2.1.DDD简介

相信了解过DDD的同学都听过网上那种官方的介绍：

• Domain Drive Design（领域驱动设计）

• 六边形架构模型

• 领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具

• ....

  说的都多多少少抽象点了，听君一席话，如听一席话，哈哈哈

在我看来常规在MVC三层架构中，我们进行功能开发的之前，拿到需求，解读需求。往往最先做的一步就是先设计表结构，在逐层设计上层dao，service，controller。对于产品或者用户的需求都做了一层自我理解的转化。

众所周知，人才是系统最大的bug。

用户需求在被提出之后经过这么多层的转化后，特别是研发需求在数据库结构这一层转化后，将业务以主观臆断行为进行了转化。一旦业务边界划分模糊，考虑不全。大量的逻辑补充堆积到了代码层实现，变得越来越难维护，到处是if/else，传说中***一样代码。

DDD所要做的就是

• 消除信息不对称
• 常规MVC三层架构中自底向上的设计方式做一个反转，以业务为主导，自顶向下的进行业务领域划分
• 将大的业务需求进行拆分，分而治之

说到这里大家可能还是有点模糊DDD与常见的mvc架构的区别。这里以电商订单场景为例。假如我们现在要做一个电商订单下单的需求。涉及到用户选定商品，下订单，支付订单，对用户下单时的订单发货。

MVC架构里面，我们常见的做法是在分析好业务需求之后，就开始设计表结构了，订单表，支付表，商品表等等。然后编写业务逻辑。这是第一个版本的需求，功能迭代饿了，订单支付后我可以取消，下单的商品我们退换货，是不是又需要进行加表，紧跟着对于的实现逻辑也进行修改。功能不断迭代，代码就不断的层层往上叠。

DDD架构里面，我们先进行划分业务边界。这里面核心是订单。那么订单就是这个业务领域里面的聚合逻辑体现。支付，商品信息，地址等等都是围绕着订单而且。订单本身的属性决定之后，类似于地址只是一个属性的体现。当你将订单的领域模型构建好之后&#x