从MVC架构角度来讲解如何演进到DDD架构

DDD这几年越来越火，资料也很多，大部分的资料都偏向于理论介绍，有给出的代码与传统MVC的三层架构差异较大，再加上大量的新概念很容易让初学者望而却步。本文从MVC架构角度来讲解如何演进到DDD架构。

从DDD的角度看MVC架构的问题

代码角度：

• 瘦实体模型：只起到数据类的作用，业务逻辑散落到service，可维护性越来越差；
• 面向数据库表编程，而非模型编程；
• 实体类之间的关系是复杂的网状结构，成为大泥球，牵一发而动全身，导致不敢轻易改代码；
• service类承接的所有的业务逻辑，越来越臃肿，很容易出现几千行的service类；
• 对外接口直接暴露实体模型，导致不必要开放内部逻辑对外暴露，就算有DTO类一般也是实体类的直接copy；
• 外部依赖层直接从service层调用，字段转换、异常处理大量充斥在service方法中；

项目管理角度：

• 交付效率：越来越低；
• 稳定性差：不好测试，代码改动的影响范围不好预估；
• 理解成本高：新成员介入成本高，长期会导致模块只有一个人最熟悉，离职成本很大；

第一层：初出茅庐

以上的问题越来越严重，很多人开始把眼光转向DDD，于是埋头啃了几本大部头的书，对以下概念有了基本的了解：

• 统一语言
• 限界上下文
• 领域、子域、支撑域
• 聚合、实体、值对象
• 分层：用户接口层、应用层、领域层、基础层

于是把MVC架构进行了改造，演进成DDD的分层架构。

DDD分层架构：

MVC架构到DDD分层架构的映射：

至此，算了基本入门了DDD架构，扩展性也得到了一定的提升。不过随着业务的发展，不断冒出新的问题：

• 一段业务逻辑代码，到底应该放到应用层还是领域层？
• 领域服务当成原来的MVC中的service层，随着业务不断发展，类也在不断膨胀，好像还是老样子啊？
• 聚