最近发现表达能力愈发下降，但求头脑清晰。记录一下DDD模型区别于MVC和MVVM架构的想法。
什么是DDD
DDD是领域驱动设计的缩写。在MVC分层后，继续对应持续化MVVM模型的进一步抽象。
1，把项目重点区域区分出来，作为核心领域设计和开发。可以区分为针对客户core domain部分，和领域逻辑部分。有点轻量化CRM加逻辑外展的模式，进一步抽象实现对应到持续化的模型。有利于中间件开发和维护。
2，以第一部分领域中的模型为基础模型进行进一步复杂设计，服务对象还是针对domain，可采用工厂模式或者选择器模式进行接口开发。
3，让技术人员和相对领域专家合作，迭代完成领域产品的特定逻辑和概念模型。深度定制领域功能和诉求，并提供服务接口，共享逻辑运算和模型结果。
对比MVC
MVC模式比较统一，小型项目快速开发合适。但是随着项目的扩展和壮大，MVC模式就越发显得笨重。具备很明显‘牵一发动全身’的特征。类比MFC迁移向WPF，成长型项目中，中心化设计对于前期发展帮助很大，但是需要在合适时机转型为模块驱动开发，慢慢弱化事物驱动开发方式。
代码角度：
- 瘦实体模型：只起到数据类的作用，业务逻辑散落到service，可维护性越来越差；
- 面向数据库表编程，而非模型编程；
- 实体类之间的关系是复杂的网状结构，成为大泥球，牵一发而动全身，导致不敢轻易改代码；
- service类承接的所有的业务逻辑，越来越臃肿，很容易出现几千行的service类；
- 对外接口直接暴露实体模型，导致不必要开放内部逻辑对外暴露，就算有DTO类一般也是实体类的直接copy；
- 外部依赖层直接从service层调用，字段转换、异常处理大量充斥在service方法中；
项目管理角度：
- 交付效率：越来越低；
- 稳定性差：不好测试，代码改动的影响范围不好预估；
- 理解成本高：新成员介入成本高，长期会导致模块只有一个人最熟悉，离职成本很大；
DDD模型特点
- 统一语言
- 限界上下文
- 领域、子域、支撑域
- 聚合、实体、值对象
- 分层：用户接口层、应用层、领域层、基础层
https://blogpic.chekuspace.com/5fKsjeq0ZqpGk7XvauObZBXrtzjMiXOpLhzJhKLUBiI.png
简单来说，DDD针对于MVC视野来看，比MVVM更具备业务抽象能力。不单纯同步看ViewModel和DataModel的统一性，更多关注领域层的聚合特点。
https://blogpic.chekuspace.com/nm2JYF5eU_NhBTjnuQzNg9SJL5ViYyHKfL_myGe5ojY.jpeg
