问题标签 [aggregateroot]

http://i.stack.imgur.com/YZXZN.png（我目前不允许嵌入图像）

我真的可以对上面的班级模型使用一些帮助。我很惭愧地说，我是“那些”在大学学习面向对象、编写考试、取得优异成绩但从未着手在我的真实世界代码中实施这些原则的开发人员之一。在开始编写应用程序设计之前，我从未真正坐下来考虑过它。因此，在单一的遗留银行应用程序开发和维护的重压下，我的设计和编码技能一直在慢慢消亡和停滞不前。经过多年的努力，我决定是时候做出改变了！我一直在深入研究设计模式、DDD、NoSQL、DI 等领域。过去两周对我来说是一段非常紧张的经历，有时我想我在为大公司和银行工作时错过的大量最佳实践和技术几乎让我流下了眼泪。我简直不敢相信这么长时间以来我与尖端技术和良好的设计方法相距甚远，而突然发生的所有事情都可能使我陷入编码瘫痪状态！我根本无法开始编码，因为我觉得我的设计需要更多调整，或者我需要对特定主题进行更多研究。不过，够了，我需要继续努力，至少对项目进行第一次迭代。突然出现的所有事情都威胁到我进入编码瘫痪状态！我根本无法开始编码，因为我觉得我的设计需要更多调整，或者我需要对特定主题进行更多研究。不过，够了，我需要继续努力，至少对项目进行第一次迭代。突然出现的所有事情都威胁到我进入编码瘫痪状态！我根本无法开始编码，因为我觉得我的设计需要更多调整，或者我需要对特定主题进行更多研究。不过，够了，我需要继续努力，至少对项目进行第一次迭代。

无论如何，足够的戏剧，关于我的问题：

我已经开始为我的高尔夫应用程序创建模型。想在一定程度上坚持 DDD，也想利用 NoSQL (RavenDB)，我开始提出以下要求。

• 我的平台堆栈是 Windows / IIS / MVC 3.0 / RavenDB
• 我需要找到我的总根！我已经着手将它们定义为我的系统中唯一能够以自己的方式持续存在的元素。其他一切我都简单地认为是聚合的“子组件”。请注意，尚未定义实际行为。
• 我的聚合根将是唯一真正保留在我的 RavenDB 文档存储中的类，它们将“按原样”保留。就实现的性能优势而言，拥有大型树状类结构似乎是 RavenDB 的最佳情况。
• 我觉得不需要存储库层（一直在关注 Ayende 的一些帖子），因为 RavenDB API 感觉流畅且非常轻量级。如果需要，我将通过控制器上的自定义操作属性简单地打开和关闭我的会话。我已经看到如果没有存储库层测试可能会很棘手，但我肯定应该能够简单地模拟一些“内存中”域对象吗？
• 对数据库的写入将发生在单独的服务层中
• 有一次我停下来问自己：“我到底要把我的领域行为放在哪里！？”。搜索网络的普遍共识似乎表明我应该让我的域（实体）没有任何行为（业务逻辑），并将其全部在我的服务层中处理。但是在阅读了一些 Eric Evans 之后，我确信我的域行为应该存在于那里......在域中！

问题 - 作为 DDD 和建筑设计领域的真正菜鸟，我至少是在正确的轨道上，还是注定要毁灭？- 任何想法、警告、建设性的批评和对上述内容的见解将不胜感激！

我在找出处理相当复杂的场景的最佳方法时遇到了一些困难。我见过很多类似的问题，但没有一个让我满意。

使用多个 OrderLine（子实体）创建一个 Order（聚合根）。根据业务规则，每个 OrderLine 必须在 Order 的生命周期内保持相同的身份。OrderLines 有许多 (20+) 属性，并且在 Order 被视为“锁定”之前可以经常发生突变。此外，还有一些必须在根级别强制执行的不变量；例如，每个订单行都有一个数量，订单的总数量不能超过 X。

在考虑对 OrderLines 进行更改时，我不确定如何对这种情况进行建模。我有 4 个我能想到的选择，但似乎没有一个令人满意：

1) 当需要修改 OrderLine 时，请使用根提供的参考。但是我失去了检查根中不变逻辑的能力。

2) 在订单上调用一个方法。我可以应用所有不变的逻辑，但是我坚持使用大量的方法来修改 OrderLine 的许多属性：

3) 如果我将 OrderLine 视为值对象，这可能会更容易，但它必须根据业务需求保持相同的身份。

4) 对于不影响不变量的修改，我可以获取对 OrderLines 的引用，并为那些影响不变量的修改执行 Order。但是，如果不变量受大多数 OrderLine 属性的影响怎么办？这个反对是假设的，因为只有少数属性可以影响不变量，但是随着我们发现更多的业务逻辑，这可能会改变。

任何建议表示赞赏......如果我很密集，请随时告诉我。

我几乎可以肯定我忽略了一些简单的事情，但它没有点击。

我有一个 Person 实体（Person 聚合的根）。我还有一个用于身份验证和授权 (Auth) 的子实体，它具有角色列表和权限列表。

我希望通过根管理对角色和权限的修改，在根上使用 AddAuthRole 等方法。

这相当简单，但是我将如何在不暴露 Auth 实体中的任何类似功能的情况下执行此操作？我不希望消费者使用孩子的参考来尝试添加和删除这些列表。

我有一种感觉，这是一些基本的 OO 概念，我应该为不知道而感到羞耻......

通过遵循 DDD 和存储库模式，是否可以返回已经包含其子数据的聚合根对象，而不是使用延迟加载？

例如，我有一个仓库实体作为聚合根，它有一个名为 location 的子对象。

在存储库上，我有一个方法来查询位置 ID，但传回仓库实体。

当我使用warehouse.location 时，EF 使用代理类来触发另一个数据库查询以检索位置数据。在我的存储库方法 FindByLocationId 中，我可以查询位置数据库表并传回包含位置数据的仓库实体吗？

我们正在使用事件溯源并从事件流中构建聚合。我有 2 个聚合 - A1 和 A2。A1 用作模板以创建 A2。A1 的尺寸可能相当大。事件溯源的基本思想是确保对应用程序状态的每次更改都被捕获到事件对象中。所以要保存 A2，我们必须在第一个事件中存储大量信息。

这种情况是常见的还是从模板创建不是一个好主意？有没有更好的方法来解决它？

我们如何告诉 Entity Framework 关于Aggregates的信息？

1. 保存聚合时，将实体保存在聚合中
2. 删除聚合时，删除聚合中的实体
3. 当两个不同的用户尝试修改同一聚合中的两个不同实体时引发并发错误
4. 加载聚合时，即使在我们访问聚合中的所有实体之前存在一些时间延迟，也要提供聚合的一致时间点视图

（实体框架 4.3.1 代码优先）

我正在对作为视频需求系统一部分的档案进行建模。想想像 Windows 资源管理器这样的存档，其中多个用户可以创建文件夹、上传视频、重组文件夹等。有业务规则（权限）确定是否允许用户执行任务（即重命名文件夹、移动文件夹、查看文件夹等）。

我已将每个文件夹建模为聚合根，将一个文件夹移动到另一个文件夹似乎会影响两个聚合根。

据我了解，我应该发送一个事件来修改另一个聚合。然而，我担心的是，如果第二个文件夹也被修改（比如从系统中删除或删除），那么我需要发送一个补偿命令来撤消第一个聚合更改。

我更喜欢某种同时处理移动（两个聚合上的更改）的事务，如果它失败，那么至少我不需要撤消移动的第一部分或引发事件的第一部分。

这让我想到，CQRS 是否适合我要解决的问题？如果是这样，我的聚合可能是错误的吗？

我知道有一百万个这样的问题。对不起。我认为我的不一样，但似乎并非如此。我是 DDD 的新手，并试图掌握它。我的部分域是这样的。位置 1-* 字段 字段 1-* 事件字段 1-* 任务 任务-员工

现在看来，AR 就是位置。如果我想获得一项特定的任务，我将不得不通过字段集合遍历任务集合中的任务。

这听起来很费力，因为我经常处理任务和事件，而且几乎从来没有一个位置。该位置用于隔离一组字段及其对应的实体。所以在 ui 中，我可以选择一个位置并获取字段列表。然后我会选择一个领域。从那里我可能会编辑其中一项任务。所以我有一组任务，我选择一个，这样我就有了任务的 ID。然后我需要遍历到 location 并获取他的 ID，这样我才能获取 AR 并遍历回任务。或者更确切地说，我会保留 AR 的 ID，以便我可以得到它。那么我是否也应该保留该字段的 ID？所以我返回到服务器的将是我想要查看的 AR.Id、Field.Id 和 Task.Id？

其次，员工当然不能是实体，它很可能是 AR。AR 上的实体可以拥有 AR 集合吗？

那么它的结构应该是这样的吗？

这使得处理修改最多的对象和遍历它们的关系变得更加容易，但它也感觉有点像普通的旧 OOP，AR 并没有真正的意义。

再说一次，我是 DDD 的新手，没有人可以通过它来进行健全性检查。请帮助我了解这些边界是如何绘制的，如果是第一种方法，是否有更简单的方法来处理实体，然后携带 AR.id、ParentParent.Id、ParentId 以及最后的对象兴趣实体.Id

感谢您的任何想法

我有这个设计：

一个产品有多个定价网格，一个网格有多个定价周期

现在我有特别优惠，当卖家创建优惠（例如 -10%）时，他可以选择将其应用于产品甚至网格（例如，他不想将优惠应用于网格“www .apartnerwebsite.com”，但他更喜欢将其应用于网格“我的网站”）。

但我不能这样做，因为没有网格 ID，我不能从根聚合中引用叶子。

我知道聚合根是客户端加载的唯一对象，聚合根中对象的所有操作都由聚合根完成。按照相同的约定，应该为聚合根定义一个存储库接口，并且对聚合根内的任何对象的任何持久性操作都应该由对应于聚合根的这个“聚合根存储库”完成。这是否意味着只应将聚合根对象传递给“聚合根存储库”以进行与聚合根的子对象相关的操作？

让我举个例子吧。

假设您有一个 School 对象和 Student 对象。由于学生没有学校就不能存在，（你可能会说一个学生可能已经离开学校，在这种情况下他/她不再是学生），所以我们有

学校是这里的总根。现在假设我们要为持久性操作定义一个存储库。

下面哪个是正确的？

1)

2)

在 1) 中，我们只在界面中公开聚合。因此，任何实现 ISchoolRepository 的 DAL 都必须从 School 对象中获取 Student 对象才能添加学生。2) 看起来更明显，建议 1) 我可能看起来很愚蠢，但纯理论中聚合根的概念会建议 1)