处理 DDD 中的嵌套聚合

2024-01-02

我刚刚开始使用 DDD,并且在弄清楚如何适应数据的关系性质时遇到了一些困难。我拥有我相信会被视为我的聚合根的东西,但聚合也有它自己的聚合。不想违反德墨忒尔定律,我想知道我的想法是否错误,并希望一些 DDD 专家可以提供一些见解。

我的聚合根是我的Account对象,它是由无数个集合组成的AccountElement实体,它们本身就是个体的逻辑分组ProductComponent实体。

An AccountElement在上下文之外Account没有任何意义,所以我对我的结论感到满意Account对象是我的聚合根,我预计该实体具有聚合Elements财产。这是ProductComponent让我困惑的收藏。该聚合在外部没有任何意义AccountElement, and really之外没有任何意义Account.

我认为我不应该访问个人ProductComponent通过点点方式到达对象,例如:

var reference = account.Elements(0).ProductComponents(0).ReferenceCode;

但同时(从域的角度来看)访问ProductComponent直接从Account entity.

我确信如果不了解我的领域,这一切都有点难以理解,但我希望这足以获得一些好的反馈。


罗伯特链接的文章是一篇很好的文章。我想补充一点,如果 ProductComponent 仅存在于 AccountElement 的上下文中,并且 AccountElement 仅存在于 Account 的上下文中,那么通过扩展,ProductComponent 就存在于 Account 的上下文中。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

处理 DDD 中的嵌套聚合 的相关文章

  • 使用 CQRS 和事件溯源时的唯一性验证

    我正在尝试使用事件源来实现我自己的 CQRS 基础设施 以更好地学习它 作为一个示例项目 我正在实现一个博客引擎 我知道它可能不是一个完美的选择 但我只想做一些真实的事情 我现在遇到的问题是验证 每个帖子都有一个shortUrl 以及sho
  • DDD是否适合所有类型的应用?

    对于这里和其他论坛提出的很多问题 我看到的一个常见反应是 您不需要为此执行 DDD 它是一个简单的 CRUD 应用程序 DDD 是一种过度设计 嗯 我是 DDD 的新手 我觉得 DDD 中有很多元素具有普遍吸引力并且可以全面使用 无论您的应
  • 使用 JPA/Spring 的(通用)DDD 存储库的方法:它看起来有问题吗?

    我对 DDD 和 JPA 还很陌生 我正在使用 JPA 和 Spring 开发一个通用存储库 我真的很喜欢文章中介绍的方法DDD 通用存储库 http codebetter com blogs gregyoung archive 2009
  • 我可以在 DDD 中拥有“不完整”的聚合吗?

    DDD 规定您只能通过实体的聚合根来访问实体 举例来说 你有一个聚合根 X 它可能有一个lot子 Y 实体的数量 现在 对于某些场景 您一次只真正关心这些 Y 实体的子集 也许您将它们显示在分页列表或其他内容中 那么是否可以实现一个存储库
  • CQRS 事件溯源:验证用户名唯一性

    我们以一个简单的 账户注册 为例 流程如下 用户访问网站 点击 注册 按钮并填写表格 点击 保存 按钮 MVC 控制器 通过读取 ReadModel 来验证用户名的唯一性 RegisterCommand 再次验证用户名唯一性 这是问题 当然
  • 在 CQRS http 应用程序中实现 Saga/Process Manager

    按照这个例子 https msdn microsoft com en us library jj591569 aspx https msdn microsoft com en us library jj591569 aspx 图3 它如何适
  • DTO 道 POCO BO

    事实上 我对这些术语以及它们之间的关系感到非常困惑 我读过有关其中每个人的一些内容 但我不了解工作流程 DTO 数据传输对象 传输值的对象BO 业务对象 域模型中的对象 用于制作业务逻辑的对象POCO 不知道 我在维基上读过定义 但什么也没
  • CQRS、DDD同步报告数据库

    我们正在尝试 CQRS 和 DDD 以及事件溯源 假设我有一位客户更新了电子邮件地址 这会触发 CustomerUpdatesEmailAddress 事件 这会进入我的操作 写入数据库 并更新表 我们的系统设计为有一个运行的 ETL 流程
  • DDD 中哪一层应该包含查询

    我有一个简单的 DDD 服务 带有文章聚合根 我使用 MediatR 和 CQRS 来分离命令和查询 在 DDD 域中不应依赖于应用程序和基础设施层 我有一个存储库 IArticleRepository 用于从文章数据库中组合一些数据 我有
  • .NET 中的 DDD / 聚合

    我一直在阅读 Evans 关于 DDD 的书 并且正在思考应该如何在 NET 中实现聚合 目前 我只能想出一种方法 将聚合隔离在单独的类库中 然而 这似乎有点矫枉过正 我更愿意将所有域对象保留在一个库中 我想知道是否有不同的方法 1 lib
  • 领域驱动设计中的 WCF 序列化和值对象模式

    Eric Evans 所著的 领域驱动设计 一书描述了称为值对象的模式 值对象的重要特征之一是它是不可变的 作为一个例子 我有一个值对象 Clinic 其中must有名字和id 为了使其成为值对象 我不提供名称和 ID 的设置器 另外 为了
  • DDD:我真的需要加载聚合中的所有对象吗? (性能问题)

    在 DDD 中 存储库加载整个聚合 我们要么加载全部 要么不加载 这也意味着应该避免延迟加载 我关心的是性能方面的问题 如果这导致将数千个对象加载到内存中怎么办 例如 聚合Customer一万回来Orders 在这种情况下 是否意味着我需要
  • 导入数据和事件溯源

    我目前正在开发一个整体系统 我希望将其引入现代并结合 DDD 和 CQRS 我收到了重新编写解决方案的导入机制的请求 并认为这可能是开始此重新架构过程的好机会 目前流程是 用户上传 CSV 系统解析 CSV 并在屏幕上显示每一行 对每一行以
  • 使用 JPA 实体作为域模型是一个好习惯吗?

    或者创建一个由域模型组成的域层并与 JPA 实体对话以进行数据库访问 两种方法的优缺点是什么 谢谢 这确实取决于您对域进行编码的方式 一般来说 在 Java 中 我更喜欢创建一组单独的 JPA 注释的 DTO 来处理持久性 此类 DTO 将
  • 定义具有多种消息类型的消息传递域

    到目前为止 我见过的大多数 F 消息传递示例都使用 2 4 种消息类型 并且能够利用模式匹配将每条消息定向到其正确的处理函数 对于我的应用程序 由于处理和所需参数的不同性质 我需要数百种独特的消息类型 到目前为止 每个消息类型都是其自己的记
  • 事件源和 SQL Server 多个关系表

    我们使用 SQL Server 2016 的事件源 我们有完整的客户产品应用程序 每个应用程序都标记为CustomerId并在事件商店中获取单个指南行项目 这是写入事件存储指南的主要标识符 产品应用程序附带许多不同的关系事物 没有引导 但有
  • 多态性:ORM 实体是领域实体还是数据实体?

    我有一个 BankAccount 表 LINQ to SQL 生成一个名为 BankAccount 的类 如下所示 global System Data Linq Mapping TableAttribute Name dbo BankAc
  • 如何在 CQRS 中处理基于集合的一致性验证?

    我有一个相当简单的域模型 涉及一系列Facility聚合根 鉴于我使用 CQRS 和事件总线来处理从域引发的事件 您如何处理集合的验证 例如 假设我有以下需求 Facility必须有一个唯一的名称 由于我在查询端使用最终一致的数据库 因此在
  • 领域驱动设计 (Linq to SQL) - 如何删除聚合的某些部分?

    我似乎对整个 DDD LinqToSql 业务感到有点困惑 我正在使用 POCOS 和 linq to sql 构建一个系统 并且我有聚合根的存储库 因此 例如 如果您有 Order gt OrderLine 类 那么您就有了 Order
  • 将 F# 类型保存到数据库

    A lot http gorodinski com blog 2013 02 17 domain driven design with fsharp and eventstore f 文章数推荐 http fsharpforfunandpr

随机推荐