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

原创
2019/07/09 15:07
阅读数 8.9K

本系列目录:

  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的思维方式和编码方式和常规做法的差距较大,很容易让大家无法短时间适应,但我恰恰就想通过这个过程,了解大家的反馈和质疑,因为我也想知道,这个东西,真正落地,还有哪些困难;
  • 所以,欢迎大家,文明拍砖,哈哈,如果有问题,能够给出具体的实际例子进行讨论更好。

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

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
38 收藏
5
分享
返回顶部
顶部