背景 几年前我总结过DDD战术设计的一些落地经验可落地的DDD(5)-战术设计,和一次关于聚合根的激烈讨论最近两年有些新的落地体验,回过头来发现,当初对这些概念的理解还是没有深入,这篇文章重新阐述下. 之前理解不到位的点有 战术设计的各个模块是的协作关系 哪些是问题空间问题,哪些是方案空间问题边界没有划分清楚. 实体和聚合根的区别理解不不深刻,实体和聚合根建模的方法不对. 以上问题将会在下文解释清楚. 战术设计拆解 DDD的战术设计即设计某个子域的领域模型以及代码落地.领域事件.领域对象.聚合根…

摘要 本篇是DDD的战术篇,也就是关于领域事件.领域对象.聚合根.实体.值对象的讨论.也是DDD系列的完结篇. 这一部分在我们团队争论最多的,也有很多月经贴,比如对资源库的操作应该放在领域服务还是领域对象中. 聚合根应不应该暴露给外部,还是要转成DTO.这些问题我们讨论了大半年,最后大家基本达成了共识,在当前的业务规模下, 这些问题没那么重要,可东可西.不会对代码的质量有啥大的影响.关于DDD的实践,与团队的水平.业务复杂度息息相关.我们的经验并不一定就适用你们团队.我将战术篇的这么多的内容放在…

可落地的DDD(5)-战术设计   摘要 本篇是DDD的战术篇,也就是关于领域事件.领域对象.聚合根.实体.值对象的讨论.也是DDD系列的完结篇.这一部分在我们团队争论最多的,也有很多月经贴,比如对资源库的操作应该放在领域服务还是领域对象中.聚合根应不应该暴露给外部,还是要转成DTO.这些问题我们讨论了大半年,最后大家基本达成了共识,在当前的业务规模下,这些问题没那么重要,可东可西.不会对代码的质量有啥大的影响.关于DDD的实践,与团队的水平.业务复杂度息息相关.我们的经验并不一定就适用你们团队…

一.引子 不知今年吹了什么风,忽然DDD领域驱动设计进入大家视野.该思想源于2003年 Eric Evans编写的"Domain-Driven Design领域驱动设计"简称DDD,Evans DDD是一套综合软件系统分析和设计的面向对象建模方法.刚好公司领导强力推荐这个,抱着学习的心态,耗时5个月,体验了一把:"DDD从入门到弃坑". 二.思想 学习网站:https://www.jdon.com/ddd.html 服务器后端发展三个阶段: 面向过程脚本:初始简单,…

前言 战术设计 战略设计为我们提供一种高层视野来审视我们的软件系统,主要包括领域/子域.通用语言.限界上下文和架构风格等概念, 而战术设计则将战略设计进行具体化和细节化,它主要关注的是技术层面的实施,也是对程序员来得最实在的地方. 战术设计的目的是保证战略的实现.在DDD中,代码就是设计本身,你不再需要那些繁文缛节的并且永远也无法得到实时更新的设计文档. 警惕贫血对象,要创建行为饱满的领域对象并不难,我们需要转变一下思维,将领域对象当做是服务的提供方,而不是数据容器,多思考一个领域对象能够提供哪…

前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇通过这个设计的Demo来谈谈博主对仓储的理解,有不对的地方还望…

前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇通过这个设计的Demo来谈谈博主对仓储的理解,有不对的地方还望…

摘要 在前面一篇介绍了如何通过DDD的思想,来调整单体服务内的工程结构,为微服务的拆分做准备.同时介绍了我们在进行微服务拆分的时候踩过的一些坑. 这篇介绍下我们最终的方案,不一定对,欢迎留言讨论. 微服务划分 问题分析 上篇介绍过我们一开始的服务划分标准 一个领域一个服务的规则去拆分, 同时为了保证领域的纯洁性,我们区分了领域服务,和前台服务.领域服务就是领域逻辑,不直接对前端暴露.前台服务组装各个领域服务,暴露给前端. 同时为了保持扩展,我们预留了一个微服务作为服务孵化器.对于领域不清晰的(比…

从遇到问题开始 当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品.所以,自然而然就想到要做一个普通电商系统,用于实现在线销售自己企业产品的目的. 再比如,我是一家互联网公司,公司有很多系统对外提供服务,面向很多客户端设备.但是最近由于各种原因,导致服务经常出故障.所以,我们希望通过各种措施提高服务的质量和稳定性.其中的一个措施就是希望能做一个灰度发布的平台,这个…

最近在做电商业务中,有关商品业务改版的一些东西,后端的架构设计采用现在很流行的微服务,有关微服务的简单概念: 微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成.系统中的各个微服务可被独立部署,各个微服务之间是松耦合的.每个微服务仅关注于完成一件任务并很好地完成该任务.在所有情况下,每个任务代表着一个小的业务能力. 关于改版的业务设计,还是想尝试 DDD 领域驱动设计,之前写的一些相关文章,都是直接进行战术设计,而非在战略设计基础上进行,所以最后可能会出现一些问题,所以这次的过程是…