分布式域驱动设计中的值对象列表

Question

我需要一些关于在我的分布式DDD应用程序中实现值对象列表的切实指导。这就是我所拥有的：

我的应用程序基于在服务器上运行的RESTful服务应用程序，该服务器为多个客户端应用程序提供服务。我的一个实体Customer有一个Region属性，它包含对许多Region值类型之一的引用。区域列表存储在后端数据库中，但我们不提供维护此列表的接口。任何更改都将直接在数据库中进行（因为它很少发生）并且很可能是名称更改而不是添加/删除。在场合，如扩展到新市场，可以添加新项目，因此要求列表是“动态的”。

在其中一个客户端UI中编辑客户记录时，我需要在下拉列表中显示区域列表，其中所选项目与客户域对象的Region属性相关联。

我可以处理它的UI方面但我很模糊应该如何在我的域层中获取和维护区域列表。我是否有单独的RegionRepository，还是应该从CustomerRespository中检索列表？如果Customer是引用Value Object的唯一实体，该怎么办？如果多个实体引用了VO，那会改变方法吗？

我实际上有很多这些类型的查找，并且不希望为每个查找创建单独的存储库（和Web服务），除非建议使用它们。我已经考虑过为API提供单一的Lookup服务，但是在我更好地掌握这条路线的影响之前，我一直犹豫不决。

虽然列表项是“键控的”，但它们不符合具有自己标识的实体的定义，除了在父域对象（在本例中为Customer）的上下文中之外，它们不存在。所以我假设它们是Value Objects，这很好。但是，我不清楚我应该如何构建我的应用程序以允许客户端检索上述情况的VO列表。

Answer 1

您可以将它们放在任何有意义的地方。如果您选择公开该属性并实现该存储库，则不会破坏任何DDD契约。

作为一个例子，我使用以下内容：

interface IAddress
{
    List<State> GetStatesByCountry (string country);
}

我也有

interface ITaxes
{
    List<State> GetStates ();
}

在我的情况下，这两个都是由ILookupRepository实现的，因为这就是特定后端系统的设计方式。然而在我们的另一个系统中，我们有一个实际的ICountryRepository，因为后端和服务都与上面的系统不同，对于那种情况更有意义。

Answer 2

我发现这个问题的关键是退后一步并评估查找列表实际存在的上下文。例如，区域列表可能是销售区域，地理区域等。识别这一点通常会导致我进入另一个上下文对象，该列表作为子项存在。