(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. 在长事务，复杂处理的过程当中，可读性更强；
3. 因为每个命令操做被有序的概括到充血模型中，在追踪实体行为时，很是方便；

欢迎拍砖

这个规范，仅仅是参考DDD的部分思路，并不是彻底照搬DDD，由于领域分析里有太多太多概念，并且因为是一种很是抽象的分析模式，没法量化，更难造成标准。因此，我在这里只是吸收了其中一部分思路，而后以充血模型为基础，并给出一些能够量化的标准，来让团队更容易将这个规范落地。

因此，某成程度来讲，它或许已经不是DDD的范畴了。

总之：

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

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