Database design 推广DDD中的公共实体

我的系统中有一些常见的实体和价值对象，我只想对它们进行概括，以便更好地管理。

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

ProductTag
BlogTag
NewsTag 

还有关于分类、评论和。。。现在我只想在数据库中做一个概括，列出所有标签、类别和注释。。。现在，为它们中的每一个（标记、类别等）创建一个聚合，并在数据库中为它们创建一个完整的表，然后在其他标记或类别之间创建联接，这是一个好主意吗？（我的意思是其他是productTag、BlogTag等）

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

我需要对这些实体进行更好的管理，我认为最好的处理方法是为每个实体创建整体集合，你认为呢

…现在我只想在数据库中做一种概括，列出所有标记、类别和注释的列表

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

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

---

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

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

---

因此，不需要做经济高效且错误的事情，因为对于数据库来说，只需要简化查询操作

感谢您的回答，是的，不需要解决数据库中的UI问题。