本系列目录：
- 改变与优势
- 领域分析基础
- 读写隔离
- 充血模型之实体
- 充血模型之Service
- 关于重构与落地
前言
大家好，我是一名普普通通的后端研发。
领域驱动设计（Domain Driven Design,DDD）是我大学开始就接触的概念，但一直到工作这么久了，却一直感觉像是雾里看花，仿佛懂了，却一直找不到说服自己用它的理由。
一年前，我又一次开始重新审视这个概念。终于，这一次，我结合实际项目场景和DDD的理念后，分析出一个以DDD为基础的编码规范。它不是一个很具象的技术组件，而更侧重于领域的分析，代码结构的编排等。
作为第一篇文章，我直接见山，介绍它在开发中的改变以及所带来的优势。
开发中的改变
- 读写隔离：查询操作与命令操作（增删改）通过文件（如Java的class）进行强制隔离
- 充血模型：实体类中允许出现行为操作，如
order.cancel()
带来的优势
读写隔离
- 对查询来说，采用
ReadOnly=true，从代码规范上“强制”保证查询的纯净性与无害性 - 系统真正的流程变动都在命令，所以保证业务流程的聚焦，不受到查询的干扰
- 查询【重性能-轻事务】，修改则反之，不同的模块隔离，更便于框架进行统一优化，比如代码复用性，AOP优化，安全权限等等
- 如果为了性能考虑，要进行物理持久化层面的读写分离，也很方便
充血模型
- 明确领域责任划分，实体更具有实际意义，更符合面向对象的设计理念；
- 在长事务，复杂处理的过程中，可读性更强；
- 由于每一个命令操作被有序的归纳到充血模型中，在追踪实体行为时，非常方便；
欢迎拍砖
这个规范，仅仅是参考DDD的部分思路，并非完全照搬DDD，因为领域分析里有太多太多概念，而且由于是一种非常抽象的分析模式，无法量化，更难形成标准。所以，我在这里只是吸取了其中一部分思路，然后以充血模型为基础，并给出一些可以量化的标准，来让团队更容易将这个规范落地。
所以，某成程度来说，它或许已经不是DDD的范畴了。
总之：
- 我写下本系列的几篇小文，算不上什么高深的技术文章，更多的是一个探讨与尝试，因为我个人真的挺喜欢这种分析和编码方式，所以想分享给大家；
- 而正式由于DDD的思维方式和编码方式和常规做法的差距较大，很容易让大家无法短时间适应，但我恰恰就想通过这个过程，了解大家的反馈和质疑，因为我也想知道，这个东西，真正落地，还有哪些困难；
- 所以，欢迎大家，文明拍砖，哈哈，如果有问题，能够给出具体的实际例子进行讨论更好。
感谢！ 从下一篇开始进入正题：领域分析基础
