DDD这几年越来越火,资料也很多,大部分的资料都偏向于理论介绍,有给出的代码与传统MVC的三层架构差异较大,再加上大量的新概念很容易让初学者望而却步。本文从MVC架构角度来讲解如何演进到DDD架构。
从DDD的角度看MVC架构的问题
代码角度:
- 瘦实体模型:只起到数据类的作用,业务逻辑散落到service,可维护性越来越差;
- 面向数据库表编程,而非模型编程;
- 实体类之间的关系是复杂的网状结构,成为大泥球,牵一发而动全身,导致不敢轻易改代码;
- service类承接的所有的业务逻辑,越来越臃肿,很容易出现几千行的service类;
- 对外接口直接暴露实体模型,导致不必要开放内部逻辑对外暴露,就算有DTO类一般也是实体类的直接copy;
- 外部依赖层直接从service层调用,字段转换、异常处理大量充斥在service方法中;
项目管理角度:
- 交付效率:越来越低;
- 稳定性差:不好测试,代码改动的影响范围不好预估;
- 理解成本高:新成员介入成本高,长期会导致模块只有一个人最熟悉,离职成本很大;
第一层:初出茅庐
以上的问题越来越严重,很多人开始把眼光转向DDD,于是埋头啃了几本大部头的书,对以下概念有了基本的了解:
- 统一语言
- 限界上下文
- 领域、子域、支撑域
- 聚合、实体、值对象
- 分层:用户接口层、应用层、领域层、基础层
于是把MVC架构进行了改造,演进成DDD的分层架构。
DDD分层架构:
MVC架构到DDD分层架构的映射:
至此,算了基本入门了DDD架构,扩展性也得到了一定的提升。不过随着业务的发展,不断冒出新的问题:
- 一段业务逻辑代码,到底应该放到应用层还是领域层?
- 领域服务当成原来的MVC中的service层,随着业务不断发展,类也在不断膨胀,好像还是老样子啊?
- 聚合包含多个实体类,这个接口用不到这么多实体,为了性能还是直接写个SQL返回必要的操作吧&#x