(1) 基于领域分析设计的架构规范 - 改变与优势

本系列目录：

1. 改变与优势
2. 领域分析基础
3. 读写隔离
4. 充血模型之实体
5. 充血模型之Service
6. 关于重构与落地

前言

大家好，我是一名普普通通的后端研发。

领域驱动设计（Domain Driven Design,DDD）是我大学开始就接触的概念，但一直到工作这么久了，却一直感觉像是雾里看花，仿佛懂了，却一直找不到说服自己用它的理由。

一年前，我又一次开始重新审视这个概念。终于，这一次，我结合实际项目场景和DDD的理念后，分析出一个以DDD为基础的编码规范。它不是一个很具象的技术组件，而更侧重于领域的分析，代码结构的编排等。

作为第一篇文章，我直接见山，介绍它在开发中的改变以及所带来的优势。

开发中的改变

1. 读写隔离：查询操作与命令操作（增删改）通过文件（如Java的class）进行强制隔离
2. 充血模型：实体类中允许出现行为操作，如order.cancel()

带来的优势

读写隔离

1. 对查询来说，采用ReadOnly=true，从代码规范上“强制”保证查询的纯净性与无害性
2. 系统真正的流程变动都在命令，所以保证业务流程的聚焦，不受到查询的干扰
3. 查询【重性能-轻事务】，修改则反之，不同的模块隔离，更便于框架进行统一优化，比如代码复用性，AOP优化，安全权限等等
4. 如果为了性能考虑，要进行物理持久化层面的读写分离，也很方便

充血模型

1. 明确领域责任划分，实体更具有实际意义，更符合面向对象的设计理念；
2. 在长事务，复杂处理的过程中，可读性更强；

欢迎拍砖

这个规范，仅仅是参考DDD的部分思路，并非完全照搬DDD，因为领域分析里有太多太多概念，而且由于是一种非常抽象的分析模式，无法量化，更难形成标准。所以，我在这里只是吸取了其中一部分思路，然后以充血模型为基础，并给出一些可以量化的标准，来让团队更容易将这个规范落地。

所以，某成程度来说，它或许已经不是DDD的范畴了。

总之：

• 我写下本系列的几篇小文，算不上什么高深的技术文章，更多的是一个探讨与尝试，因为我个人真的挺喜欢这种分析和编码方式，所以想分享给大家；
• 而正式由于DDD的思维方式和编码方式和常规做法的差距较大，很容易让大家无法短时间适应，但我恰恰就想通过这个过程，了解大家的反馈和质疑，因为我也想知道，这个东西，真正落地，还有哪些困难；
• 所以，欢迎大家，文明拍砖，哈哈，如果有问题，能够给出具体的实际例子进行讨论更好。

感谢！ 从下一篇开始进入正题：领域分析基础