Question

所以我试图遵循域驱动设计方法，并且不确定如何处理需要CRUD操作的查找表。这是一个用来证明我的问题的人为例子。

我们说我有一个人类

public class Person
{
    public string Address { get; private set; }
}

我的数据库有一个人员表和一个地址表。 People表有一个Address_Id列，它是Address表的外键。显而易见的是，由于存在外键关系，因此您无法将人员记录添加到人员表中，地址值不会存在于地址表中。

在我的应用程序中，Person是聚合根，因此具有关联的存储库。使用存储库，我加载了也加载相关地址的人。

我的问题是如何在地址表上执行CRUD操作？遵循DDD原则，我不认为我应该为地址表创建一个存储库。

我的应用程序的要求是，在创建新的Person对象时，会显示一个地址下拉列表，用户将从中选择一个地址。他们不允许手写地址，他们必须从已存在的地址中选择。因此，地址表上的CRUD操作。系统管理员需要管理地址查找表，以便向创建Person对象的用户显示正确的选择。

同样，这是一个非常人为的例子，我得知没有人会设计这样的系统。它只是帮助说明问题。

Answer 1

您是否自己编辑或检索地址？存储库本质上是关系数据库的业务对象的映射器，它应该封装对象的持久化方式，因此您不必担心它。

如果对象持久存储在多个表中，那么业务逻辑就不必知道，所以除非你需要自己编辑Address对象，否则我不会为Address添加一个存储库。

Answer 2

好吧，但我想属性string Address应为Address Address。

在这种情况下，当您在Person上存储PersonRepository时，如果底层商店中不存在某些Address，则整个存储库将使用其特定于技术的实现在Addresses关系表中为您创建整个地址注册表。

另外，我猜你会在现有的数据映射器上使用存储库 - 一个OR / M - 它应该可以轻松地管理这个案例：它只是将整个属性映射为多对一关联。

实际上我相信存储库应该像您在自己的问题中提到的那样存储根聚合。

这取决于您自己的域名。如果一个地址可以单独存在，因为它可以与0个或更多人相关联，那么您应该考虑使用特定的AddressRepository添加地址，使用它注册地址，之后您可以始终将地址与某个Person相关联。

Answer 3

IMO，你有两个使用案例：1）保存Person对象，但在2）列出所有可用的地址之前，能够选择正确的地址。

所以，我会创建一个AddressRepository，可能不是一个CRUD，但仅用于获取实体。