在DDD中概括公共实体

Question

我的系统中有一些常见的实体和价值对象，我只是想将它们概括为更好的管理。

我正在使用不同类型的聚合和上下文开发大规模应用程序，并通过流畅的nhibernate映射域聚合。我的系统中有不同类型的标签：

ProductTag
BlogTag
NewsTag 

并且关于类别，评论和...也有相同的故事现在我只想在数据库中进行一种概括，以获得所有标签，类别和评论的列表......现在这是一个好主意为每个人创建一个聚合（标签，类别，...），并在数据库中为他们创建一个完整的表，然后在其他标签或类别之间创建连接??（我的意思是其他是productTag，BlogTag，.. 。）

我将所有这些标记作为值对象，如何在另一个聚合根中拥有值对象的实例？（例如Tag（聚合根）中的productTag（VO））。

我需要对这些实体有更好的管理我认为处理它的最佳方法是为每个实体创建整体聚合，你觉得怎么样？

Answer 1

  

...现在我只想在数据库中进行一种概括，以获得所有标签，类别和评论的列表......

如果我错了，请纠正我，但我认为你正试图通过数据库来解决纯粹的UI问题。您真的需要域模型中所有标签/类别/评论的列表，还是只在UI中的某个位置列出？你想要引入额外的聚合根只是为了能够从存储库中查询它们吗？您应该避免仅为了用户界面或持久性机制而丰富您的域模型。

但是，如果确实需要这些值对象的公共接口（例如，当业务规则需要知道系统中的所有标记时），那么这个概念应该反映在您的域模型中，而不仅仅是在数据库中

就个人而言，我赞成基于domain events的实施。每个聚合都会引发它自己的事件（ProductTaggedEvent，BlogTaggedEvent，NewsCommentedEvent，...），其中包含有关具体值对象在其聚合上下文中的所有必要信息。一个单独的组件（另一个聚合或甚至是有界的上下文）将监听这些事件并创建一个专用模型，其中包含可以轻松查询的结构中的所有标记/类别/注释。它可以与您的其他聚合一起保存在同一个数据库中，甚至可以保存在具有完全不同存储机制的另一个存储库中（因为它通常由大多数CQRS实现完成）。无论如何，如果您创建专门满足例如需求的第二个模型/概念，则无需概括任何内容。你的用户界面。

Answer 2

在与我的一位同事讨论之后，我发现没有必要对这些实体进行概括，并且在域关注和数据库关注之间存在很多差异。 首先，不可能将值对象作为另一个聚合根中的引用（聚合根可以具有其他聚合根的引用）。 我只想通过域驱动的设计概念来解决数据库问题，正如上面提到的@StevePuder，如果你不需要在UI中列出它们，就不需要做这样的事情。 虽然我需要在UI中列出产品标签，产品类别，博客标签和...的列表，但我不需要在sql server中的另一个表中单独协作它们！要做到这一点，我可以简单地创建一个查询服务来获取产品标签和... 所以，没有必要做一个具有成本效益和错误的事情只是因为数据库关注使查询操作更简单！