上图是一张普通地图,最刺眼的就是边界? 非常好奇地图绘制工程师是如何描绘如此弯曲多变的边界的?强制行政区域还是人群历史原因自然的人以群分? 我们再换个视角,对工程师或者架构师来说,微服务的边界如何划分呢? 基于DDD设计方法论中的概念 限界上下文 来划分微服务的边界: 背景 架构师小李正在团队推行DDD设计方法论,领域建模和系统建设过程中,很多岗位需要参加进来,比如产品经理,领域专家,项目经理,架构师,开发经理,测试经理.对同样的领域知识,不同的人可能有不同的认识,交流起来存在一定障碍. 假如你

1 界限上下文概念的出现 当开发一个电子商务系统的时候,会给系统划分很多子域,销售子域是核心子域,此外还有物流子域,商品子域等支撑子域.在这些子域里面,一个商品product在销售子域和商品子域里面外面对它的关注内容是一样的,但是在物流子域就不一样了.在商品子域,我们会常常使用它的单价属性.名称属性等,但是在物流子域我们就不关心它的单价.名字了.它只是一个贴了运单号的包裹.之所以出现这种差异,就是环境发生了变化,在此我们引入界限上下文的概念. 2 界限上下文的使用 针对每一个子域都引入界限上下文

前面一片文章,我介绍了Conference案例的核心业务,为了方便后面的分析,我这里再列一下: 业务描述 Conference是这样一个系统,它提供了一个在线创建会议以及预订会议座位的平台.这个系统的用户有两类:1)客户,可以创建和管理会议:2)会议座位预定者,可以预订会议座位.具体的关键业务描述如下: 客户创建一个会议,并录入会议的基本信息,比如名称.时间段.地点,等:会议创建后,系统会为客户自动生成一个AccessCode,客户可以通过AccessCode访问自己创建的会议: 客户定义某个会

记得之前在规划和设计微服务架构的时候,张队长给了我一个至今依然记忆深刻的提示:『你的设计蓝图里为什么没有看到DDD的影子呢?』 随着对充血模型的领域认知的加深,我越加感觉到DDD的重要性.但是DDD内容繁多,是不是要深入去了解呢,我觉得不必入坑太深,个人浅见,它最核心的一点就是针对贫血模型的不足而设计,把原先传统的贫血模型里的业务逻辑层拎出来,融入到Domain层,这样面对复杂业务的规模化变更,我们只需要专注于Domain即可. 回到主题,我们要了解的是微服务和DDD到底有什么关系呢? 因为在互

Conference业务简介 Conference是这样一个系统,它提供了一个在线创建会议以及预订会议座位的平台.这个系统的用户有两类: 1:客户,可以创建和管理会议. 2:会议座位预定者,可以预订会议座位. 具体的关键业务描述如下: 1.客户登陆系统,客户可以创建一个会议,并录入会议的基本信息,比如名称.时间段.地点,参会人数等. 2.客户定义某个会议的座位类型,可以定义多个,每个座位类型包含的信息有:名称.座位价格.座位数量 ,根据座位类型自动生成座位编号. 3.客户发布或取消发布某个会议,

前言 哈喽大家好,DDD领域驱动设计系列又开始了,前天周二的那篇入门文章中,也收到了一定的效果(写小说的除外),同时我也是倍感鸭梨,怎么说呢,DDD领域驱动设计已经有十年历史了,甚至更久,但是包括我在内的一批技术人员还是对其不是很明白,这几天我也是日思夜想,怎样才能说的明白,怎样才能把这个高高在上的思想落在实践上,可惜的是国内栗子比较少,国外文章比较少,只能硬啃了,所以更需要大家一起来讨论,这里要说一下,是一起讨论推动,而不是内心去拒绝,而一直和多层架构做对比,这样不仅不利于学习,也无法带动我的

上篇文章主要讲述了经销商上下文的需求与POCO对象,这篇文章主要讲述该界限上下文的仓储与领域逻辑的实现. 关于界限上下文与EF Core数据访问上下文参考产品上下文相应的实现,这里不再累述. 因为在经销商上下文中有两个聚合,一个是经销商聚合,一个是登录聚合,所以我们需要实现两个仓储接口: 1.经销商仓储接口定义: public interface IDealerRepository { void CreateDealer<T>(T dealer) where T : class, IAggre

在本系列前面的文章中,我们主要讨论了产品上下文与经销商上下文相关的实现,大家对DDD的方法与架构已经有了初步的了解. 但是在这两个界限上下文中,业务逻辑很简单,也没有用到更多的值对象的内容.从这篇文章开始,我们来讲讲订单界限上下文实现的内容, 里面的业务逻辑相对复杂一些,而且有大量值对象的引入来进行逻辑的处理. 订单上下文的需求主要是生成相应的订单项,每个订单项中有相关的订单产品和购买数量并生成订单项总额.订单项总PV,同时订单项总额 和订单项总PV会累加到订单总额和订单总PV中,同时会根据订单

摘要 前面两篇介绍了DDD的目标管理.DDD的工程结构调整.这篇讨论微服务的划分.微服务是目前后端比较流行的架构体系了,那么如何做好一个微服务的划分?一个微服务的粒度应该是多大呢?这篇主要介绍如何结合DDD进行领域划分. 工程结构代码 上篇介绍了可落地的DDD的(2)-为什么说MVC工程架构已经过时 很多朋友留言说,有没有sample code,要不然太湿了,不是很明白.这里写了个sample. 就以一个博客网站为例 page1:博客列表页: 展示所有用户发表的博客 page2: 个人介绍页:有

一.前言     DDD(领域驱动设计)的一些介绍网上资料很多,这里就不继续描述了.自己使用领域驱动设计摸滚打爬也有2年多的时间,出于对知识的总结和分享,也是对自我理解的一个公开检验,介于博客园这个平台也算是对DDD的推广尽了一份绵薄之力.一开始接触这个东西是在2014年,真的觉得像是发现了一片新大陆一般,对我整个程序开发视野有了新的理解,但是像[Vaughn Vernon]<实现领域驱动设计>里写的那样,景色虽好,可是自己很长一段时间内很混乱,理不清眼前的陌生世界,因为它与传统的观念完全不同

去年就打算总结一下,结果新换的工作特别忙,就迟迟没有认真动手.主要内容是很多初学DDD甚至于学习很长时间的同学没有弄明白DDD是什么,适合什么情况.这世界上没有银弹,抛开了适合的场景孤立的去研究DDD,在学习过程中还可以,但是应用到实际项目时就会遇到各种坑,到头来各种妥协,我看到很多同学遇到这种情况,最后怪DDD,说DDD不实用云云.另有一些都没细了解过就抨击反对的,事实上,要想否定个东西,你总要了解了才有发言权. 一.误区 综合起来主要有一下几种误区: 1.1.DDD更高级,可以替代三层,为了

最近发现下面关于上下文的理解有些问题,不太好改,暂时先不改了 承前:大型系统的支撑,应用系统开发思想的变迁,DDD实践切入点(一) 从大比例结构入手已经开始了系统的建设,大家都知道需求是会不断变化不断深入的,刚开始自然是模糊的大比例结构对将要进行的系统有一个初步的认识,在不断细化的过程中明确需求.前一篇中粗略的对主要的问题进行了描述,可以看出主要有两个部分,申请单管理和审批流转,两者都与申请单关联,但关注点不同,申请单管理的重点是对申请单本身信息的维护,而审批流转中主要是以申请单的部分信息为依据

上一篇:<IDDD 实现领域驱动设计-理解领域和子域> <实现领域驱动设计>前两章内容,基本上读完了,和<领域驱动设计>不同的是,它把很多的概念都放在前面进行讲述了,比如领域精炼.界限上下文等等,在<领域驱动设计>中,是很靠后的内容,不过这样也好,可以让你从一个大局的视角去看待问题,由广到细的思路学习,我觉得也蛮好的.另外,随着一点一点的学习,你会发现,领域驱动设计越来越有意思了,有很多"新鲜"的东西等待发现. 一张很重要的图(无意间搜到

连续写了两篇文章,这一篇我想是序的完结篇了.结合用户注册的例子再将他简单丰富一下.在这里只添加一个简单需求,就是用户注册成功后给用户发一封邮件.补充一下之前的代码 public class DomainService { public void Register(User user) { if (_userRepository.IsLoginIdExist(user.LoginId)) { throw new Exception("用户名已存在"); } _userRepository

DDD实践切入点(二) 承前:大型系统的支撑,应用系统开发思想的变迁,DDD实践切入点(一) 从大比例结构入手已经开始了系统的建设,大家都知道需求是会不断变化不断深入的,刚开始自然是模糊的大比例结构对将要进行的系统有一个初步的认识,在不断细化的过程中明确需求.前一篇中粗略的对主要的问题进行了描述,可以看出主要有两个部分,申请单管理和审批流转,两者都与申请单关联,但关注点不同,申请单管理的重点是对申请单本身信息的维护,而审批流转中主要是以申请单的部分信息为依据进行流转的决策,所以两者申请单的模型有

如何开始DDD(完) 连续写了两篇文章,这一篇我想是序的完结篇了.结合用户注册的例子再将他简单丰富一下.在这里只添加一个简单需求,就是用户注册成功后给用户发一封邮件.补充一下之前的代码 public class DomainService { public void Register(User user) { if (_userRepository.IsLoginIdExist(user.LoginId)) { throw new Exception("用户名已存在"); } _use

要实现软件设计.软件开发在一个统一的思想.统一的节奏下进行,就应该有一个轻量级的框架对开发过程与代码编写做一定的约束. 虽然DDD是一个软件开发的方法,而不是具体的技术或框架,但拥有一个轻量级的框架仍然是必要的,为了开发一个支持DDD的框架,首先需要理解DDD的基本概念和 核心的组件. 一.什么是领域驱动设计(DDD) 首先要知道DDD是一种开发理念,核心是维护一个反应领域概念的模型(领域模型是软件最核心的部分,反应了软件的业务本质),然后通过大量模式来指导模型设计 与开发. DDD的一般过程是

前面我们花了14篇的文章来给大家介绍经典DDD的概念.架构和实践.这篇文章我们来做一个完整的总结,另外生成一个Api接口文档. 一.DDD解决传统的开发的几大问题: 没有描述需求的设计模型:而是直接通过数据库表的方式体现,也就是需求与设计是脱节的. 编码的架构也没有与设计和需求对应起来. 业务逻辑与技术混在一起:业务逻辑可能直接调用的数据访问,这样把业务逻辑与数据访问的技术混在一起. 开发没有层次感和节奏感:系统没有一个统一的约束,开发人员没有一个统一的节奏,这主要体现在随意的编码. Bug 定

前言 领域驱动设计是一个开放的设计方法体系,目的是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题,本文将介绍领域驱动的相关概念. 一.软件复杂度的根源 1.业务复杂度(软件的规模) 软件的需求决定了系统的规模.当需求呈现线性增长的趋势时,为了实现这些功能,软件规模也会以近似的速度增长.由于需求不可能做到完全独立,导致出现相互影响相互依赖的关系,修改一处就会牵一发而动全身.就好似城市的一条道路因为施工需要临时关闭,此路不通,通行的车辆只能改道绕行,这又导致了其他原本已经饱

领域驱动设计的概念 ​ 大家都知道软件开发不是一蹴而就的事情,我们不可能在不了解产品(或行业领域)的前提下进行软件开发,在开发前通常需要进行大量的业务知识梳理,然后才能到软件设计的层面,最后才是开发.而在业务知识梳理的过程中,必然会形成某个领域知识,根据领域知识来一步步驱动软件设计,就是领域驱动设计(DDD,Domain-Driven Design)的基本概念 . 为什么需要 DDD ​ 在业务初期,功能大都非常简单,普通的 CRUD 就基本能满足要求,此时系统是清晰的.但随着产品的不断迭代和演

何为DDD DDD不是架构设计方法,不能把每个设计细节具象化,DDD是一套体系,决定了其开放性,体系中可以用任何一种方法来解决这些问题,但是如果一些关键问题没有具体方案落地,可能让团队无所适从. 有的小伙伴觉得DDD太虚了,具体在我们进行业务代码编写落地中DDD主要解决什么问题呢? 总结起来说主要目的有两点: 建立业务术语,统一PM/RD/QA需求沟通术语. 梳理业务边界,将业务领域逻辑内聚. 搞定DDD要解决的问题 如何进行领域建模 如何识别Bounded Context 如何在战术层面寻找对