DDD聚合、领域服务、应用服务

一、聚合(Aggregate)

在DDD中,聚合被视为设计和实现领域模型的基础,它提供了一种清晰的方式来组织领域对象,并定义了领域对象之间的关系和行为。

简单来说就是为了实现“高内聚,低耦合”。

高内聚

高内聚是指模块内部各个元素之间相关性非常高,彼此之间联系紧密,同时与外部的联系尽可能的小。

优点:

  1. 提高代码重用性:高内聚的模块代码可以被其他模块重用,减少代码的重复编写。

  2. 提高模块的可维护性:高内聚的模块可以更容易地进行维护和修改,因为模块内部的代码联系紧密,修改一个模块不会影响其他模块。

  3. 提高代码的可读性:高内聚的模块代码易于阅读和理解,因为它们的功能单一,逻辑清晰,易于追踪和理解。

  4. 降低耦合度:高内聚的模块之间耦合度低,各模块之间变化不会相互影响,不会带来连锁反应,从而提高软件系统的稳定性。

低耦合

指系统中各个组件或模块的耦合度程度较低,即它们之间相互依赖性较小。

优点:

  1. 提高代码的可扩展性:由于模块之间相互独立,新增模块时只需要考虑如何与现有模块进行连接,并不需要对原有的模块进行修改或重构,从而降低了扩展的成本。

  2. 提高代码的可测试性:低耦合的模块能够更容易地进行单元测试,从而提高代码的质量和可靠性。

高内聚与低耦合也是微服务的一个核心。 

聚合根(Aggregate Root)

将关系紧密的实体放到一个聚合中,每个聚合中有一个实体作为聚合根,所有对于聚合内对象的访问都通过聚合根来进行,外部对象只能持有对聚合根的引用,聚合根不仅仅是实体,还是所在聚合的管理者。

聚合根具有以下特征:

  • 聚合根代表一组实体和值对象的集合,它们具有一定的业务意义,并且需要以事务性的方式进行一致性管理。
  • 聚合根提供了一个单一的入口点,在整个系统中只有它才能被直接访问和修改,这有助于确保整个聚合的一致性。
  • 聚合根的标识符(ID)可以唯一地标识整个聚合,在应用中可以用于查询和访问聚合。

聚合的划分

在进行聚合的划分时,需要考虑以下几个因素:

  1. 业务领域:聚合应该尽可能反映业务领域中的真实概念。

  2. 明确边界:聚合边界应该明确,避免与其他聚合产生重叠,保证聚合间的独立性和可重用性,实体是否是整体和部分的关系。

  3. 业务操作:聚合应该考虑业务操作的一致性和原子性,避免在操作过程中出现数据的不一致性。

  4. 性能考虑:聚合的大小应该在一定范围内,避免太大或太小,影响系统的性能。

聚合中,真正的难点在于对聚合的划分,在不同的业务逻辑当中,实体可能划分为聚合也可能划分为聚合根,也正因此,聚合太过于灵活,不好对其具体划分,小聚合有助于进行微服务的拆分。

二、领域服务与应用服务

2.1、领域服务

领域模型是对业务领域的概念和规则进行抽象和建模,它将业务领域的要素转化为软件构件。通过领域模型的建立,可以更好地理解业务流程。

领域模型一般包括以下几个部分:

  • 实体(Entity):表示领域中的对象或事物,具有属性和行为。
  • 值对象(Value Object):表示领域中的值,比如时间、金额、地址等,一般没有自己的标识,也不会发生变化。
  • 聚合(Aggregate):由一组相关的实体和值对象组成,形成一个有边界的整体,同时具有一些内部的约束和规则。
  • 领域服务(Domain Service):表示领域中的某些特定行为,比如计算、验证等。
  • 领域事件(Domain Event):表示领域中发生的一些重要事件,比如订单被创建、库存不足等。

领域模型通常用作以下几个方面:

  1. 确定业务需求:通过领域模型,开发人员能够更好地理解业务领域中的各个对象之间的关系和行为,从而更好地识别并满足业务需求。

  2. 指导软件设计:领域模型可以指导软件设计,尤其是在使用面向对象编程语言进行开发时。它可以帮助开发人员创建高质量、可维护和可扩展的软件系统。

  3. 驱动开发过程:领域模型可以成为开发过程中的一个指导原则,而不只是一个可执行代码的设计或静态文档。它可以帮助开发团队明确应用程序的规范及实现,提高开发效率。

  4. 支持测试:领域模型可以帮助测试人员更好地理解业务需求和系统功能,从而更有效地规划和执行测试工作。

对于聚合内的业务,编写在领域服务中。

2.2、应用服务

应用服务通常负责建立领域模型和基础设施之间的联系,执行用例和协调领域对象的操作。它不包含任何业务逻辑和状态,而是将请求委托给领域模型和基础设施,然后将结果返回给客户端。

应用服务通常被用于以下方面:

  1. 处理用户请求和响应:应用服务可以接收来自用户界面的请求,并调用领域层的服务和领域对象进行处理和响应,然后将结果返回给用户界面。

  2. 调用多个领域对象:应用服务可以协调多个领域对象之间的交互,并确保它们按照正确的顺序执行。

  3. 实现业务流程:应用服务可以实现业务流程,如订单处理等等,通过协调多个领域对象和服务的实现完成。

  4. 事务处理:应用服务可以管理事务的边界和范围,并确保所有操作都能成功或者回滚。

应用服务是业务逻辑和持久化层之间的桥梁,负责协调领域对象和基础设施服务(如数据库、消息队列等)。

对于聚合外的业务,编写在应用服务中。

 

  • 5
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
内容简介 · · · · · · 领域驱动设计(DDD)是教我们如何做好软件的,同时也是教我们如何更好地使用面向对象技术的。它为我们提供了设计软件的全新视角,同时也给开发者留下了一大难题:如何将领域驱动设计付诸实践?Vaughn Vernon 的这本《实现领域驱动设计》为我们给出了全面的解答。 《实现领域驱动设计》分别从战略和战术层面详尽地讨论了如何实现DDD,其中包含了大量的最佳实践、设计准则 和对一些问题的折中性讨论。《实现领域驱动设计》共分为14 章,在DDD 战略部分,《实现领域驱动设计》向我们讲解了领域、限界上下文、上下文映射图和架构等内容,战术部分包括实体、值对象、领域服务领域事件、聚合和资源库等内容。一个虚构的案例研究贯穿全书,这对于实例讲解DDD 实现来说非常有用。 《实现领域驱动设计》在DDD 的思想和实现之间建立起了一座桥梁,架构师和程序员均可阅读,同时也可以作为一本DDD 参考书。 举报 作者简介 · · · · · · 作者:Vaughn Vernon是一个经验丰富的软件工匠,在软件设计、开发和架构方面拥有超过25年的从业经验。他提倡通过创新来简化软件的设计和实现。从20世纪80年代开始,他便开始使用面向对象语言进行编程;在 20世纪 90年代早期,他便在领域建模中应用了领域驱动设计,那时他使用的是Smalltalk语言。他在很多业务领域都有从业经验,包括航空、环境、地理、保险、医学和电信等领域。同时,Vaughn在技术上也取得了很大的成功,包括开发可重用的框架和类库等。他在全球范围之内提供软件咨询和演讲,此外,他还在许多国家教授《实现领域驱动设计》的课程。你可以通过www.VaughnVernon.co访问到他的最新研究成果。他的Twitter:@VaughnVernon。
第一部分 背景知识 第1章 应重视的价值,也是对过去几年的沉重反思 1.1 总体价值 1.2 应重视的架构风格 1.2.1 焦点之一:模型 1.2.2 焦点之二:用例 1.2.3 如果重视模型,就可以使用领域模型模式 1.2.4 慎重处理数据库 1.2.5 领域模型与关系数据库之间的阻抗失配 1.2.6 谨慎处理分布式 1.2.7 消息传递很重要 1.3 对过程的各个组成部分的评价 1.3.1 预先架构设计 1.3.2 领域驱动设计 1.3.3 测试驱动开发 1.3.4 重构 1.3.5 选择一种还是选择组合 1.4 持续集成 1.4.1 解决方案(或至少是正确方向上的一大步) 1.4.2 从我的组织汲取的教训 1.4.3 更多信息 1.5 不要忘记运行机制 1.5.1 有关何时需要运行机制的一个例子 1.5.2 运行机制的一些例子 1.5.3 它不仅仅是我们的过错 1.6 小结 第2章 模式起步 2.1 模式概述 2.1.1 为什么要学习模式 2.1.2 在模式方面要注意哪些事情 2.2 设计模式 2.3 架构模式 2.3.1 示例:层 2.3.2 另一个示例:领域模型模式 2.4 针对具体应用程序类型的设计模式 2.5 领域模式 2.6 小结 第3章 TDD与重构 3.1 TDD 3.1.1 TDD流程 3.1.2 演示 3.1.3 设计效果 3.1.4 问题 3.1.5 下一个阶段 3.2 模拟和桩 3.2.1 典型单元测试 3.2.2 声明独立性 3.2.3 处理困难因素 3.2.4 用测试桩替换协作对象 3.2.5 用模拟对象替换协作对象 3.2.6 设计含义 3.2.7 结论 3.2.8 更多信息 3.3 重构 3.4 小结 第二部分 应用DDD 第4章 新的默认架构 4.1 新的默认架构的基础知识 4.1.1 从以数据库为中心过渡到以领域模型为中心 4.1.2 进一步关注DDD 4.1.3 根据DDD进行分层 4.2 轮廓 4.2.1 领域模型示例的问题/特性 4.2.2 逐个处理特性 4.2.3 到目前为止的领域模型 4.3 初次尝试将UI与领域模型挂接 4.3.1 基本目标 4.3.2 简单UI的当前焦点 4.3.3 为客户列出订单 4.3.4 添加订单 4.3.5 刚才我们看到了什么 4.4 另一个维度 4.4.1 领域模型的位置 4.4.2 孤立或共享的实例 4.4.3 有状态或无状态领域模型实例化 4.4.4 领域模型的完整实例化或子集实例化 4.5 小结 第5章 领域驱动设计进阶 5.1 通过简单的TDD实验来精化领域模型 5.1.1 从Order和OrderFactory的创建开始 5.1.2 一些领域逻辑 5.1.3 第二个任务:OrderRepository+OrderNumber 5.1.4 重建持久化的实体:如何从外部设置值 5.1.5 获取订单列表 5.1.6 该到讨论实体的时候了 5.1.7 再次回到流程上来 5.1.8 总览图 5.1.9 建立OrderRepository的伪实现 5.1.10 简单讨论一下保存 5.1.11 每个订单的总量 5.1.12 历史客户信息 5.1.13 实例的生命周期 5.1.14 订单类型 5.1.15 订单的介绍人 5.2 连贯接口 5.3 小结 第6章 准备基础架构 6.1 将POCO作为工作方式 6.1.1 实体和值对象的PI 6.1.2 是否使用PI 6.1.3 运行时与编译时PI 6.1.4 PI实体/值对象的代价 6.1.5 将PI用于存储库 6.1.6 单组存储库的代价 6.2 对保存场景的处理 6.3 建立伪版本机制 6.3.1 伪版本机制的更多特性 6.3.2 伪版本的实现 6.3.3 影响单元测试 6.4 数据库测试 6.4.1 在每次测试之前重置数据库 6.4.2 在测试运行期间保持数据库的状态 6.4.3 测试之前重置测试所使用的数据 6.4.4 不要忘记不断演变的模式 6.4.5 分离单元测试和数据库调用测试 6.5 查询 6.5.1 单组查询对象 6.5.2 单组查询对象的代价 6.5.3 将查询定位到哪里 6.5.4 再次将聚合作为工具 6.5.5 将规格用于查询 6.5.6 其他查询选择 6.6 小结 第7章 应用规则 7.1 规则的分类 7.2 规则的原则及用法 7.2.1 双向规则检查:可选的(可能的)主动检查,必需的(和自动的)被动检查 7.2.2 所有状态(即使是错误状态)都应该是可保存的 7.2.3 规则应该高效使用 7.2.4 规则应该是可配置的,以便添加自定义规则 7.2.5 规则应与状态放在一起 7.2.6 规则应该具有很高的可测试性 7.2.7 系统应阻止我们进入错的状态 7.3 开始创建API 7.3.1 上下文,上下文,还是上下文 7.3.2 数据库约束 7.3.3 将规则绑定到与领域有关的转换,还是绑定到与基础架构有关的转换 7.3.4 精化原则:所有状态,即使是错误状态,都应该是可保存的 7.4 与持久化有关的基本的规则API的需求 7.4.1 回到已发现的API问题上 7.4.2 问题是什么 7.4.3 我们允许了不正确的转换 7.4.4 如果忘记检查怎么办 7.5 关注与领域有关的规则 7.5.1 需要合作的规则 7.5.2 使用基于集合的处理方法 7.5.3 基于服务的验证 7.5.4 在不应该转换时尝试转换 7.5.5 业务ID 7.5.6 避免问题 7.5.7 再次将聚合作为工具 7.6 扩展API 7.6.1 查询用于设置UI的规则 7.6.2 使注入规则成为可能 7.7 对实现进行精化 7.7.1 一个初步实现 7.7.2 创建规则类,离开最不成熟的阶段 7.7.3 设置规则列表 7.7.4 使用规则列表 7.7.5 处理子列表 7.7.6 一个API改进 7.7.7 自定义 7.7.8 为使用者提供元数据 7.7.9 是否适合用模式来解决此问题 7.7.10 复杂规则又是什么情况 7.8 绑定到持久化抽象 7.8.1 使验证接口成为可插入的 7.8.2 在保存方面实现被动验证的替代解决方案 7.8.3 重用映射元数据 7.9 使用泛型和匿名方法 7.10 其他人都做了什么 7.11 小结 第三部分 应用PoEAA 第8章 用于持久化的基础架构 8.1 持久化基础架构的需求 8.2 将数据存储到哪里 8.2.1 RAM 8.2.2 文件系统 8.2.3 对象数据库 8.2.4 关系数据库 8.2.5 使用一个还是多个资源管理器 8.2.6 其他因素 8.2.7 选择和前进 8.3 方法 8.3.1 自定义手工编码 8.3.2 自定义代码的代码生成 8.3.3 元数据映射(对象关系(O/R)映射工具) 8.3.4 再次选择 8.4 分类 8.4.1 领域模型风格 8.4.2 映射工具风格 8.4.3 起点 8.4.4 API焦点 8.4.5 查询风格 8.4.6 高级数据库支持 8.4.7 其他功能 8.5 另一个分类:基础架构模式 8.5.1 元数据映射:元数据的类型 8.5.2 标识字段 8.5.3 外键映射 8.5.4 嵌入值 8.5.5 继承解决方案 8.5.6 标识映射 8.5.7 操作单元 8.5.8 延迟加载/立即加载 8.5.9 并发控制 8.6 小结 第9章 应用NHibernate 9.1 为什么使用NHibernate 9.2 NHibernate简介 9.2.1 准备 9.2.2 一些映射元数据 9.2.3 一个小的API示例 9.2.4 事务 9.3 持久化基础架构的需求 9.3.1 高级持久化透明 9.3.2 持久化实体的生命周期所需的特定特性 9.3.3 谨慎处理关系数据库 9.4 分类 9.4.1 领域模型风格 9.4.2 映射工具风格 9.4.3 起点 9.4.4 API焦点 9.4.5 查询语言风格 9.4.6 高级数据库支持 9.4.7 其他功能 9.5 另一种分类:基础架构模式 9.5.1 元数据映射:元数据类型 9.5.2 标识字段 9.5.3 外键映射 9.5.4 嵌入值 9.5.5 继承解决方案 9.5.6 标识映射 9.5.7 操作单元 9.5.8 延迟加载/立即加载 9.5.9 并发性控制 9.5.10 额外功能:验证挂钩 9.6 NHibernate和DDD 9.6.1 程序集概览 9.6.2 ISession和存储库 9.6.3 ISession、存储库和事务 9.6.4 得到了什么结果 9.7 小结 第四部分 下一步骤 第10章 博采其他设计技术 10.1 上下文为王 10.1.1 层和分区 10.1.2 分区的原因 10.1.3 限界上下文 10.1.4 限界上下文与分区有何关联 10.1.5 向上扩展DDD项目 10.1.6 为什么对领域模型——SO分区 10.2 SOA简介 10.2.1 什么是SOA 10.2.2 为什么需要SOA 10.2.3 SOA有什么不同 10.2.4 什么是服务 10.2.5 服务中包括什么 10.2.6 深入分析4条原则 10.2.7 再来看一下什么是服务 10.2.8 OO在SOA中的定位 10.2.9 客户-服务器和SOA 10.2.10 单向异步消息传递 10.2.11 SOA如何提高可伸缩性 10.2.12 SOA服务的设计 10.2.13 服务之间如何交互 10.2.14 SOA和不可用的服务 10.2.15 复杂的消息传递处理 10.2.16 服务的可伸缩性 10.2.17 小结 10.3 控制反转和依赖注入 10.3.1 任何对象都不是孤岛 10.3.2 工厂、注册类和服务定位器 10.3.3 构造方法依赖注入 10.3.4 setter依赖注入 10.3.5 控制反转 10.3.6 使用了Spring.NET框架的依赖注入 10.3.7 利用PicoContainer.NET进行自动装配 10.3.8 嵌套容器 10.3.9 服务定位器与依赖注入的比较 10.3.10 小结 10.4 面向方面编程 10.4.1 热门话题有哪些 10.4.2 AOP术语定义 10.4.3 .NET中的AOP 10.4.4 小结 10.5 小结 第11章 关注UI 11.1 提前结语 11.2 模型-视图-控制器模式 11.2.1 示例:Joe的Shoe Shop程序 11.2.2 通过适配器简化视图界面 11.2.3 将控制器从视图解耦 11.2.4 将视图和控制器结合起来 11.2.5 是否值得使用MVC 11.3 测试驱动的Web窗体 11.3.1 背景 11.3.2 一个示例 11.3.3 领域模型 11.3.4 GUI的TDD 11.3.5 Web窗体实现 11.3.6 小结 11.3.7 用NMock创建模拟 11.4 映射和包装 11.4.1 映射和包装 11.4.2 用表示模型来包装领域模型 11.4.3 将表示模型映射到领域模型 11.4.4 管理关系 11.4.5 状态问题 11.4.6 最后的想法 11.5 小结 11.6 结束语 第五部分 附录 附录A 其他领域模型风格 附录B 已讨论的模式的目录
ddd领域驱动设计)是一种软件架构设计方法,它将业务领域的核心概念和逻辑放在设计的中心,强调通过深入理解和建模领域来推动软件开发。ddd不仅仅是一种技术,更是一种思维方式。 领域驱动设计视频教程能够很好地帮助学习者理解和掌握ddd的概念和实践技巧。这样的教程通常会结合实际案例和示例代码,通过讲解和演示来阐述ddd的各个方面,包括领域模型、聚合根、实体、值对象、领域服务应用服务等内容。 通过视频教程,学习者可以更直观地了解ddd的实际运用,减少理解上的障碍。视频教程通常包含了各种图示、动画和演示,更容易帮助学习者理解和记忆相关概念和原则。 针对ddd的视频教程可以在更短的时间内提供更多的信息,可以循序渐进地引导学习者从基础知识到高级实践。学习者可以跟随视频进行练习,通过实际操作加深对ddd的理解和运用能力。 另外,ddd的视频教程也可以提供学习者互动交流的机会。学习者可以通过评论区或者在线讨论组与讲师和其他学习者交流讨论,获取更多的帮助和指导。 综上所述,ddd领域驱动设计视频教程能够以直观、互动和循序渐进的方式帮助学习者理解和运用ddd的思维方式和实践技巧。对于那些对ddd感兴趣或者希望提升自己软件设计能力的人来说,这样的视频教程是非常有价值的学习资源。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值