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

本系列目录: 改变与优势领域分析基础读写隔离充血模型之实体充血模型之Service关于重构 前言大家好,我是一名普普通通的后端研发。领域驱动设计(Domain Driven Design,DDD)是我大学开始就接触的概念,但一直到工作这么久了,却一直感觉像是雾里看花,仿佛懂了,却一直找不到说服自己用它的理由。一年前,我又一次开始重新审视这个概念。终于,这一次,我结合实际项目场景和DDD的理念后,分析出一个以...

(3) 基于领域分析设计的架构规范-读写隔离

本系列目录: 改变与优势领域分析基础读写隔离充血模型之实体充血模型之Service关于重构 思想概述读取操作必须是无害的,暂时不考虑大并发把服务器压垮这种极端场景,就一般而言,我们可以说,一个合格的查询接口所达到的效果应该是: 无论你执行多少次查询,系统的数据都是不会发生变化的所以,对于一个陌生的系统,如果对方给了你【增删改查】四个接口,那么再没有深入了解业务的情况下,你首先进行测试的接口,一定是查询接口为...

(5) 基于领域分析设计的架构规范 - 充血模型之Service

本系列目录: 改变与优势领域分析基础读写隔离充血模型之实体充血模型之Service关于重构 Entity与Service,相爱相杀好,接上一篇。既然采用order.cancel()这种模式,那么一个新的问题来了: 并不是,只是一部分放在实体类,其余的命令操作,依旧会采用一种Service来做。所以,我们必然需要一个可以清晰量化的规范,来确定这些行为该放在哪里:如果一个命令操作,只修改了一个聚合对象内部的相...

(6) 基于领域分析设计的架构规范 - 关于重构

本系列目录: 改变与优势领域分析基础读写隔离充血模型之实体充血模型之Service关于重构 DDD落地之殇DDD这类架构真正落地困难,我觉得,有几个原因: 规范多,尤其是充血模型,需要对业务有更清晰的认识代码结构相比无状态扁平化开发,层次深,模块划分更严格,所以,至少从文件数上来说,是更多的(代码行数倒是不一定多)DDD并不是一个“刚性”需求,如果不按这个规范来做,系统一样可以跑起来,所以,很多规范处在一个...
关于我们 联系我们 友情链接 LMLPHP后院 
本站由 LMLPHP 强力驱动 ©2014-2019 LMLPHP 耗时0.016175(s)
2019-07-23 19:42:10 1563882130