Java .NET中的DDD/聚合

我一直在读Evans关于DDD的书，并在思考如何在.NET中实现聚合。目前，我只能想出一个办法；在单独的类库中隔离聚合。然而，这似乎有点过分（我更喜欢将所有域对象保存在一个库中），我想知道是否有不同的方法

1 lib/aggregate的理由如下：聚合根需要知道它所负责的对“子对象”的所有访问，聚合根也可以返回子对象作为其成员的结果。因此，这些子对象的成员（聚合根所需）不能公开。因此，您唯一的选择是将它们设置为内部（因为它们仍然需要由聚合根调用）。但是，通过将所有聚合放在一个项目中，仍然可以从已获得子对象的其他域对象访问这些成员。这是不可取的，因为它允许绕过聚合根。通过分离不同库中的所有聚合，解决了这个问题

其他一些信息：

我已经签出了，他们将每个聚合（包括所有子对象的类）打包到不同的包中。只能从聚合根目录调用的成员没有访问修饰符（例如：

Delivery.updateOnRouting

）。在java中，没有访问修饰符的成员是（只能从同一个包中获得）。所以这是正确的行为

但是，将所有域对象放在一个类库中，然后将相应的成员公开。对我来说，这似乎是不正确的

我只能想出一个办法； 将骨料隔离在单独的容器中 类库。然而，这似乎是错误的 有点过分了

更像是一堆滥杀滥伤。这样做的开销将是巨大的，您确实不想要几十个项目，这种方法在任何非平凡的应用程序中创建这些项目

Therefore, members (needed by the aggregate root) of these sub-objects can't be made public.

我认为这一结论过于僵化，不切实际，埃文斯并不提倡这一点。是的，他说Agg根负责创建和访问该根中的其他对象，但是

首先，聚合根倾向于重叠。如果在两个不同的根中需要一个小部件，无论出于什么原因，它都是必需的。所以你真的不能只让它（在本例中是小部件）对一个根可用，而不是对另一个根可用

第二，我认为（我的解释和我的书没有出版！）关于对象访问的Agg根的概念更多的是一种惯例而不是教条。信条是在该根的上下文中满足客户机请求，从而简化域。更重要的是为聚合根开发一个接口，然后让客户机通过该接口来满足他们的需求。如果您可以限制对（任何）客户端不需要的对象的访问（使用任何聚合根），请务必这样做

HTH，
Berryl

除了您问题的（有趣的）理论方面，我认为您问题的一个实际答案是使用名称空间来分离聚合。在.NET中，您将类放在名称空间中。名称空间结构独立于项目结构，您可以在单个项目中放置多个名称空间，这些名称空间在编译时会生成单个程序集

---

您可以使用它将所有域类放在一个程序集中，并且它们之间仍然有分隔。

我认为您不希望为其他程序集隐藏“子对象”的类定义。您可能认为不能从其他聚合根引用它们，但如果希望基于这些子对象创建表示模型，该怎么办？您需要从其他程序集访问它们

---

因此，从DDD的角度来看，您可能是正确的，但我认为您不希望您的代码将此反映到您建议的极端。这将成为非常不切实际的代码。

聚合是DDD中最困难的概念之一。你大部分都是对的。我建议用“成员资格”这一术语来表达总体概念比引入“子对象”这一术语更为直接

是，对象不能是多个聚合的成员。哪一个将是最终的执行者？通过删除成员并孤立另一个聚合中的其他成员，一个聚合根可以很容易地使另一个聚合无效。您是正确的，在一个对象似乎需要多个聚合中的成员身份的场景中，该对象必须是一个独立的实体，即它成为新聚合的根。（它可能有也可能没有额外的成员，但如果没有，那么它当然会成为它自己的一个成员的总和。）

是的，确实存在一个集合来强制执行不变量。就持久性而言，它也是单个工作单元或单个事务。聚合根最终负责其整个成员资格中的所有不变量，这一定是因为，例如，不变量的失败可能导致持久性失败，而聚合负责将聚合作为一个可行的持久性工作单元进行维护

然而，这是微妙而困难的一部分，最终责任并不意味着总量也是主要的执行者。就像我们在司法系统中所拥有的一样，法院最终是确定法律问题的最终场所，在实施最终法治的地方，法律也会得到执行。但实际执行（和合规）发生在系统的许多层面。事实上，在一个秩序井然的社会中，大多数强制执行法律规则的活动——不变量的执行——都应该在你上法庭之前就发生，你甚至不应该依赖于例行的上法庭。（虽然在DDD中，您可以始终