Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >领域驱动设计之聚合与聚合根

领域驱动设计之聚合与聚合根

作者头像
用户1910585
发布于 2018-05-11 07:33:35
发布于 2018-05-11 07:33:35
2.9K0
举报

对实体与值对象等进行关联设计后,就应该进行聚合的划分以及聚合根的确定。

首先我们需要明确为什么需要进行聚合的划分?

原来我们的系统对领域划分的最小单位通常是模块,比如客户信息管理模块、雇员信息管理模块。但模块的划分对于设计来说,还是显得粒度太粗。

一.聚合与聚合根

1.定义了对象之间清晰的关系和边界,并实现领域模型的内聚。我的理解是:一个聚合内的对象才具有强关联,对象的关联设计应该是针对一个聚合中的实体与实体或实体与值对象之间。(比如一个下订单的领域中,订单(实体)、订单项(实体)以及订单状态(值对象)应该为一个聚合,订单与订单项有关联、订单与订单状态有关联)。

2.必须将聚合作为一个修改数据的单元。

3.一个聚合必须有一个聚合根,根是聚合中的一个实体,通常聚合中其他实体需要依赖于聚合根,其他实体不能没有聚合根而单独存在,从业务的角度来看它是没有单独存在的意义的。比如在第1点中,订单应该是聚合根,因为订单项与订单状态两个对象在没有订单的情况下是没有意义的。

4.对一个聚合中实体的访问或操作,必须通过这个聚合的聚合根开始,主要的目的是这样可以保证不变的一致性规则。比如在第1点中,订单有一个订单总额属性,订单项有一个当前项金额的属性,有一个规则是订单总额为订单项总额之和,如果其他聚合绕过订单聚合根而直接操作订单项实体,则操作后,很难保证不变的一致性规则,如果通过订单聚合根操作订单项,而订单聚合根负责业务规则的一致性,这样就能够保证了。所以聚合根的一个重要职责是负责维护本聚合内部的一致性。

5.在对聚合进行查询或操作时,整个聚合是作为一个整体,不能直接查询聚合内部某个非根的对象。

二.识别聚合

识别聚合经过理论和实际的项目开发,我认为应该从以下几个方面进行聚合划分

1.哪些实体或值对象在一起才能够有效的表达一个领域概念。

2.对象之间是否必须保持一些固定的规则。

3.聚合不要设计太大,否则会有性能问题以及业务规则一致性的问题。

4.聚合中的实体和值对象应该具有相同的生命周期,并应该属于一个业务场景。

三.识别聚合根

1.一个聚合只有一个聚合根,聚合根是可以独立存在的,聚合中其他实体或值对象依赖与聚合根。

2.只有聚合根才能被外部访问到,聚合根维护聚合的内部一致性。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2015-11-25 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
领域驱动设计之聚合与聚合根实例一
通过一个实例来说明如何划分聚合与聚合根 场景:一个下订单的业务,一个订单必须有相应的客户信息,订单下有订单项,每个订单项必须有相应的产品信息,产品有分类的信息。 1.根据这个基本的需求,我们初步确定的
用户1910585
2018/05/11
2.1K0
DDD领域驱动设计实战-理解聚合(Aggregate)和聚合根(AggregateRoot)
实体和值对象组成聚合,再根据业务,将多个聚合划定到同一限界上下文,并在限界上下文内完成领域建模。
JavaEdge
2021/02/23
17.5K5
DDD领域驱动设计实战-理解聚合(Aggregate)和聚合根(AggregateRoot)
实现领域驱动设计pdf_领域驱动设计实例
在上一部分,分层架构的目的是为了将业务规则剥离出来在单独的领域层中进行实现。再回顾一下领域驱动设计的分层中应用层代码的实现。
全栈程序员站长
2022/09/20
1.6K0
实现领域驱动设计pdf_领域驱动设计实例
领域驱动设计 (DDD) 总结
DDD (Domain-Driven Design),即领域驱动设计是思考问题的方法论,用于对实际问题建模,它以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具,然后将这些概念设计成一个领域模型。由领域模型驱动软件设计,用代码来实现该领域模型。所以,DDD 的核心是建立正确的领域模型。
剑影啸清寒
2020/07/15
3.2K0
领域驱动设计 (DDD) 总结
如何运用领域驱动设计 - 聚合
出处:https://www.cnblogs.com/uoyo/p/12061334.html
李明成
2020/02/12
6760
DDD领域驱动设计的概念解析
在学习 DDD领域驱动设计 的过程中,这种方法包括特别的抽象概念,晦涩难懂,本文结合作者理解,对其方法论中的一些概念进行解析。
憧憬博客
2021/06/02
1.2K0
领域驱动设计——术语篇
随着微服务架构的普及,领域驱动设计(DDD)又重回软件设计战场。虽然团队内不少项目已经开始尝试,使用DDD指导项目的设计与开发,但还是有不少同学对DDD缺乏基础了解。因此,本文结合书本的定义及个人理解,对DDD中关键概念进行梳理,避免沟通时的歧义。毕竟DDD提倡使用通用语言,业务层面应该使用通用语言,技术层面也应该统一术语。
liliane
2022/07/27
8440
学习分享:DDD领域驱动设计指导微服务实践
把问题空间分割为规模更小且易于处理的若干子问题。分割后的问题需要足够小,以便一个人单枪匹马就能够解决他们;其次,必须考虑如何将分割后的各个部分装配为整体。分割得越合理越易于理解,在装配成整体时,所需跟踪的细节也就越少。即更容易设计各部分的协作方式。评判什么是分治得好,即高内聚低耦合。以火车为例,每个车厢都要符合承重要求,行李车厢承重能力要高于其他车厢,车厢间的连接要牢固且易于拆解,有足够的灵活性方便转弯。另外大件行李应该单独存放,避免占用普通车厢的空间,餐车应该在整个列车的中间,方便用餐
公众号_松华说
2019/07/16
1K0
学习分享:DDD领域驱动设计指导微服务实践
领域驱动设计阶段知识总结
领域用来限定业务范围,范围就是边界,这就是DDD不断强调边界的原因。 DDD的领域就是这个边界内要解决的业务问题域。在研究和解决业务问题时,DDD会按照一定的规则将业务领域进行细分,当领域细分到一定程度后,DDD会将问题范围限定在特定的边界内,在这个边界内建立领域模型,进而用代码实现领域模型,解决相应业务问题。 业务范围可能也很大,如果把这个范围看成是一个空间的话,那它同时存在“问题空间”和“解决方案空间”。问题空间是从业务需求方面来看,而解决方案空间是从实现软件方面来看,两者有一些细微的区别的,最终用子域来划分问题空间,用限界上下文来划分解决方案空间。
jack.yang
2025/04/05
970
领域驱动设计简介(下篇)
正如我们已经指出的那样,大多数DDD系统可能会使用OO范例。因此,我们对领域模型的元素可能很熟悉,例如实体,值对象和模块。例如,如果您是Java程序员,那么将DDD实体视为与JPA实体基本相同(使用@Entity注释)就足够安全了。
lyb-geek
2022/03/10
5290
领域驱动设计简介(下篇)
领域驱动设计-下
分层架构设计就是为了帮助我们达到高内聚、低耦合复用性设计和扩展性设计。整洁架构、CQRS、六边形架构等微服务架构都旨在实现“高内聚低耦合”,而分层架构基本原则是每层只能与位于其下方的层发生耦合。分层架构又分为两种:
用户7353950
2022/06/23
8140
领域驱动设计-下
领域驱动设计之实体、值对象、领域服务
建立领域模型的第一步就是需要识别出实体、值对象与领域服务。 一.实体 1.实体是领域中需要唯一标识的领域概念。通常在业务中,需要唯一标识与区分的对象并需要持续对它进行跟踪,这样的对象我们认为是实体。这里的唯一标识通常指的是业务上的唯一标识,比如订单号、雇员工号等信息,而不是数据库中因为技术需要存储的自增int id或Guid列。 2.如果两个实体所有状态都一样,但如果标识不一样,就是两个不同实体。比如订单对象就应该是实体,就算两个订单的订单日期、订单总额等信息都一样,只要标识不一样,比如订单号,我们就认为它
用户1910585
2018/05/11
3.7K0
万字长文助你上手软件领域驱动设计 DDD
作者:faryrong,腾讯 CSIG 后台开发工程师 最近看了一本书《解构-领域驱动设计》,书中提出了领域驱动设计统一过程(DDDRUP),它指明了实践 DDD 的具体步骤,并很好地串联了各种概念、模式和思想。因此,我对书本内容做了梳理、简化,融入自己的理解,并结合之前阅读的书籍以及实践经验,最终形成这篇文章。希望可以帮助大伙理顺 DDD 的各种概念、模式和思想,降低上手 DDD 的门槛。 1.背景 领域驱动设计(DDD)由 Eric Evans 提出,并一经《领域驱动设计:软件核心复杂性应对之道》的发布
腾讯技术工程官方号
2022/03/29
2.1K0
领域驱动设计(DDD)实践之路(三):如何设计聚合
这是“领域驱动设计实践之路”系列的第三篇文章,分析了如何设计聚合。聚合这个概念看似很简单,实际上有很多因素导致我们建立不正确的聚合模型。本文对这些问题逐一进行剖析。
2020labs小助手
2020/05/14
1.4K0
DDD 领域驱动设计落地实践系列:战略设计和战术设计
通过前面的文章介绍,相信大家对于什么是 DDD 有了初步的了解,知道它是一种微服务的架构设计方法论,为我们解决如何建立领域模型,如何实现微服务划分等提供了方向和指导。但是对于如何具体落地使用 DDD,可能大家还是一脸懵 B 的状态,因此从本文开始以及后面的文章将对如何进行 DDD 落地进行详细的阐述。在这其中还是会涉及到 DDD 中的一些重要概念,原本想着在一篇文章中介绍所有的概念,但是我觉得,概念总是在它该出现的时候出现才会让大家印象深刻,否则这些概念只是死板的概念,我们不清楚他为什么出现以及可以解决什么问题。
慕枫技术笔记
2023/03/20
9290
DDD 领域驱动设计落地实践系列:战略设计和战术设计
领域驱动设计精粹(中)
领域驱动设计学习拦路虎之一就是众多的概念,第一次接触这些概念会有一定的理解成本,不过正是这些概念支撑起的领域驱动设计,接下来会以电商为例对其中的核心概念做介绍。
知一
2022/09/23
9430
领域驱动设计精粹(中)
领域驱动设计的基础知识总结
1. 什么是领域(Domain) 我们所做的软件系统的目的都是来解决一系列问题,例如做一个电商系统来在线销售自己企业的产品;做一个灰度发布平台来提升服务的质量和稳定性。任何一个系统都会属于某个特定的领域,例如: 论坛是一个领域:要做一个论坛,那这个论坛的核心业务是确定的:比如用户发帖、回帖等核心基本功能; 电商系统是一个领域:只要是电商领域的系统,那核心业务就是:商品浏览、购物车、下单、减库存、付款交易等核心环节; 同一个领域的系统都具有相同的核心业务,因为他们要解决的问题的本质是类似的。因此可以推断:一个
butterfly100
2018/04/17
1.1K0
领域驱动设计的基础知识总结
领域驱动设计
本文对《领域驱动设计-软件复杂性应对之道》一书进行高度凝练,梳理了领域驱动设计的架构图、基本要素和重要概念。从细节入手,以小见大,你想知道的定义,这里都有。
kaiwest
2025/01/16
790
领域驱动设计(DDD)理论启示
过去几年通天塔一直处于快速的业务能力建设和架构完善的阶段,以应对不断增长的业务需求和容量、高可用等技术需求,现在通天塔平台已经能满足集团主站的大部分活动、频道搭建和运营能力,主流程的新需求越来越少,个性化需求和非标准化流程的数据源和服务接入的需求越来越多,有些甚至是京东零售体系外的,同时通天塔技术和产品也在积极主动寻求变化和创新,这些因素结合在一起驱动通天塔孵化出了一个以技术为导向的项目:通天塔积木,旨在构建一个基于完全开放的前端SDK和后端数据源&服务、高度灵活和强大的积木画布、能够快速移植和部署到任何第三方IT环境的活动搭建解决方案,这套方案的初衷和设计理念也契合了京东国际化赋能和PaaS化的战略。目前通天塔积木已经取得阶段性成果,已开始赋能京东国内和国际站,但如何应对异常复杂的积木业务逻辑和不可预知的业务变化,构建业务和底层技术基础实施的完全解耦的系统,一直是我们面对的巨大挑战。也是时候从更高视角来看清问题和源头,思考一种能应对和控制业务复杂度、具备强扩展性和弹性的解决方案。纵观我们的目标,DDD这个词不知不觉映入了我的眼帘。
物流IT圈
2020/03/16
1.8K0
领域驱动设计(DDD)理论启示
「首席架构看设计」权威领域驱动设计(DDD)简介
今天的企业应用程序无疑是复杂的,并依赖一些专门技术(持久性,AJAX,Web服务等)来完成它们的工作。作为开发人员,我们倾向于关注这些技术细节是可以理解的。但事实是,一个不能解决业务需求的系统对任何人都没有用,无论它看起来多么漂亮或者如何很好地构建其基础设施。
架构师研究会
2019/10/11
8200
「首席架构看设计」权威领域驱动设计(DDD)简介
相关推荐
领域驱动设计之聚合与聚合根实例一
更多 >
领券
💥开发者 MCP广场重磅上线!
精选全网热门MCP server,让你的AI更好用 🚀
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档