在我们的项目中，我们试图应用Bounded Context意识形态，我们遇到了一些明显的性能问题。例如，我们有不同的类（在不同的上下文中）来表示系统中的用户：我们核心域的上下文中的Person和安全上下文中的User。因此，我们为每个聚合都有两个不同的存储库，但它们在数据库中使用相同的表，有时会访问相同的数据。
在这种情况下，是否存在最小化db往返的常见解决方案？是否有处理它的ORM，或者我们应该自己编写一些缓存系统？
更新：数据库来自传统应用，我们必须“按原样”使用
答案 0 :(得分：3)
因此，我们为每个聚合提供了两个不同的存储库，但是 他们在数据库中使用相同的表，有时访问相同的表 数据
您在同一个表中存储了两个聚合这一事实表明设计存在问题。在这种情况下，似乎你有两个有界的上下文 - 核心域的BC（人在这里）和身份/访问BC（用户在这里）。 BC是相关的，后者可以看作是前者的上游。核心域中的Person在身份BC中具有对应的User，但它们并不完全相同。
除了BC之间的这种关系外，还有关于行为所有权的问题。例如，Person和User都可以具有名称，并且要确定的是谁拥有更改名称的行为。这可以通过几种方式实现。人可能有自己的名称，更改应传播到身份BC。同样，用户可以对名称进行更改，在这种情况下，必须通过同步机制将其传播给Person。
总的来说，您的问题可以通过两种方式解决。首先，您可以将Person和User聚合存储在不同的表中。任何给定的查询应该只使用这些表中的一个，并且它们可以在最终一致的事物中同步。另一种方法是将行为域模型与为查询设计的模型（read-model）分离。这样，您就可以创建一个旨在为特定屏幕提供服务并具有自定义查询的读取模型，甚至可以在ORM之外。
答案 1 :(得分：1)
如果所有用户也是Person（有时外部服务也被建模为特殊用户），则User和Person应在数据库上共享的唯一数据是其标识符。 实际上，域模型中的每个实体都应仅保留对确保其不变量所需的数据的引用。
此外，我猜用户名由用户名标识，人员用别名识别（增值税代码等）。
因此，最简单的优化技术是避免在实体中封装那些不需要确保其不变量的信息。
此外，您只需要一种有效的context mapping技术，以便在需要时轻松地从用户传递到另一个人。我为此使用了shared identifiers。
作为一个例子，您可以在User类中公开Person的标识符，这样对Person的存储库的简单查询就可以为您提供所需的数据。