DDD：如何处理存储在多个存储系统中的一个实体？

我目前正在将遗留应用程序迁移到域驱动的设计模型，我遇到了这个问题：该应用程序是关于实时管理大量联系人，包括检查重复项。每当有人保存一个新的联系人时，它必须通过一个第三方软件（它基本上是一个相似性搜索软件）的重复检查。如果通过检查，联系人将在SQL中创建，联系人的一小部分（与重复检查相关的一些核心字段）必须存储在第三方软件的数据库中。所以实体“联系人”生活在两个（同步）存储系统中，但一个系统只有一小部分字段，而SQL有50个以上的联系人字段。DDD：如何处理存储在多个存储系统中的一个实体？

现在我在想是否可以为“联系”（Contact和ContactShort）创建两种类型。因此，我还必须为这些实体创建两个存储库，并将这些存储库用于最终用于执行那些需要重复检查软件（如保存/插入方法）的操作的域服务中。

如何处理这种情况有一个很好的经验法则吗？

编辑：我仍然没有找到一个明确的解决方案，但想到更多关于它：也许在这种情况下，将重复检查存储系统与SQL DB分开是错误的。其实，我认为揭露第三方软件的方法是错误的。这是纯粹的基础设施。由于保存操作决不能在没有重复检查的情况下执行，我认为对第三方软件的调用应该在SQLRepository的内部。它绝不能离开基础架构层，因为它永远不会返回联系人的有效实体。你怎么看？

来源

2011-06-12 hoetz

相关：http://stackoverflow.com/questions/4355860/implementing-set-based-constraints-in-cqrs – 2011-06-13 19:08:42

对我来说你的建议解决方案听起来不错。在较低级别（数据访问层），您应该有两个独立的对象，它们可以访问两个不同的数据库（两个存储库，因为您需要不同的连接字符串）。如果使用相同的数据库引擎，则可以是同一个XXXRepository的两个实例，或者它可以是不同的存储库XXXRepository和YYYRepository来访问2个不同的数据库引擎）。

但是，在上层（域层和GUI），不应该对这些数据的方式和位置感到困扰。正如你所说的，你有一种服务将管道分离，以便应用程序域和上层（如GUI）不会看到下面发生的事情（在数据访问层中）。

来源

2011-06-12 13:13:37 oleksii

你是什么意思的“下一级”和“上一级”？较低级别是域层中定义的存储库接口的具体实现？ – hoetz 2011-06-13 05:34:56

@Malkier对不起，我扩大了我的答案。在较低级别下，我的意思是数据访问泛滥，高层次是任何高于这个水平的业务逻辑和GUI。较低级别将有两个存储库，但您将通过服务访问它们。只有该服务会知道如何使用2个存储库操作数据，因此您可以将域从存储层中隐藏起来。这是我的看法，因为它是错误的。 – oleksii 2011-06-13 07:45:52

我编辑了一个新想法的问题，看看。 – hoetz 2011-06-18 13:37:27

DDD：如何处理存储在多个存储系统中的一个实体？

回答

相关问题