您现在的位置是:首页 > 文章详情

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

日期:2019-07-09点击:366

本系列目录:

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

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

原文链接:https://my.oschina.net/u/4006523/blog/3071568
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章