领域驱动设计混乱

Question

我正在学习DDD的概念，并加强我的理解，我正在处理一些现实世界的例子。

我知道聚合应该只有一个通过根实体的入口点，而聚合应该只有一个存储库(如果我完全理解错了，请纠正我)。

现在假设有具有特定类型的消耗品，并且这些消耗品是从配送中心发送的。发送特定类型的消耗品取决于它们的数量，我的意思是，如果其中一个消费者的A和B型消费品的批发量为10，而这些消费品的数量低于10，那么配送中心就会发送A和B型消耗品。在这里，发送方和使用者都希望跟踪发送的包在哪里，或者它是否被传递或发送。

在这里，作为实体，我们有：

1. 耗材
2. ConsumableType
3. ConsumableActivity
4. 套餐
5. PackageItem
6. 消费者

我对前三个实体感到困惑:哪一个应该是聚合根？从一个快速的看，似乎消费品是一个强大的候选人，但另一方面，我们不关心每一个消耗品，我们只对其数量感兴趣。我们不记录10种不同的A类消耗品，但只有A型记录的数量，这是根据活动变化。在这一点上，消费实体似乎是多余的，只要看一下活动，我们就可以得到数量。例如，从零开始：

1. 中心创建“A类”10
2. 中心创建“B型”20
3. 中心发送“A”型5 ConsumerId=25
4. 中心发送“B型”15 ConsumerId=25
5. ConsumerId=25接收“A型”5
6. ConsumerId=25接受“B型”15
7. ConsumerId=25消费“A型”3
8. ConsumerId=25消费“B型”1
9. ConsumerId=25消费“A型”2

这里我们可以得出，在中心有5种A型和B型消耗品，在消费者中有0种A型，14种B型消耗品，id 25。

当然，这并不是一种有效的方法，但是在有了更多的活动之后，需要一段时间才能得到消费品的数量，因此对于每一种消费品类型，无论是对于消费者还是在配送中心，都应该有一个静态的数量字段，在这个字段中我们可以同时读取当前的数量。

我希望你能理解我为什么困惑，消费品实体看起来像根实体，但实际上它并不适合作为一个根实体，如果不是一个实体。

有人能建议我一些改进的设计或进一步阅读的建议，不仅限于客户-产品订购-订购线噩梦？

编辑:与消耗品和ConsumableType的关系是什么？如果我想在ConsumableType上执行CRUD操作(让用户添加新类型、更改或删除它们)，但是根实体是可使用的。为了保持数据完整性，我们不应该加载除根实体存储库以外的任何存储库。

编辑2:考虑产品实体及其类别实体。产品似乎是根本实体，但我们知道，没有类别，产品就不可能存在。那么，类别实体是根吗？如果是这样的话，根据DDD规则，我们只能通过遍历访问产品。但在我们的背景下，产品是我们关注的焦点。然后假设我们有两个聚合体:产品聚合和类别聚合。但这一次我们破坏了数据完整性，因为可以删除一个类别而不删除具有此类别的产品。所以我很困惑，找不到合适的解决办法。

Answer 1

我对前三个实体感到困惑:哪一个应该是聚合根？

我要说的是，很可能，您的聚合是包的，即使这个示例应该被分割成两个或多个独立的有界上下文。(创造和完成秩序是自然的界限)

与消耗品和ConsumableType的关系是什么？

这取决于您有限的上下文。除了由"A“或"B”指定的ConsumableType之外，我还不知道更多关于它的信息，我不得不说，它很可能是一个有价值的消费品。

如果我想在ConsumableType上执行CRUD操作(使用户添加新类型、更改或删除它们)，但根实体是可消耗的呢？

这很可能是一个完全不同的有界上下文(某个管理人员的上下文或不属于我们正在建模的一般工作流的上下文)，并建议对此上下文进行更多的研究。

不同示例

那么，类别实体是根吗？

聚合根是上下文中的用户与之交互的对象。假设有很多原因，因为在本例中没有完全解释上下文，最有可能的是Product是聚合根，因为这是用户最关心的。和上面的例子一样，Product将有一个存储库，它将把它的类别分配给它。在这种情况下，加载类别或层次结构列表最好由域服务提供，因为它不属于任何特定的实体实例。

另一个示例

在第一种情况下，系统管理员如何列出所有可用的字体颜色或添加新的字体颜色？

同样，系统管理员的上下文与选择字体颜色的用户的上下文不同。记住，每个上下文都是一个单一的工作流。在复杂的工作流中，可以在同一个上下文中有多个用户，但是对于管理员可能执行的CRUD操作这样的简单工作流，通常只有一个角色来处理这类工作流。在系统管理员之下，AvailableFontColor可能是内容装饰选项管理有限上下文中具有颜色值属性的实体。

有人能建议我一些改进的设计或进一步阅读的建议，不仅限于客户-产品订购-订购线噩梦？

我建议您了解更多关于有限上下文的知识，以及它们为什么是您在业务域建模中最有用(有时也是最妨碍)的工具之一。而且，不要指望在一周内就能使科学变得更完美。

我已经使用各种技术对软件进行了8年以上的建模，而且仍然有一些时候，我很难决定是否正确地建模了。我认为DDD最大的好处之一是它鼓励你接受这样一个事实:你可能从一开始就不会正确地建模，所以你应该让改变模型和重构变得容易，因为你对你的领域有了更多的了解，而不是仅仅按照你所拥有的去做，最终在你的原始模型周围产生了15种不同的复杂的封闭性，因为你从一开始就不完全理解这个领域。