分布式域驱动设计中的值对象列表
我需要一些关于在分布式 DDD 应用程序中实现值对象列表的切实指导。这是我所拥有的：
我的应用程序基于在服务器上运行的 RESTful 服务应用程序，为多个客户端应用程序提供服务。我的实体之一 Customer 具有 Region 属性，其中包含对多种 Region 值类型之一的引用。区域列表存储在后端数据库中，但我们不提供维护此列表的接口。任何更改都将直接在数据库中进行（因为这种情况很少见），并且很可能是名称更改而不是添加/删除。有时，例如扩展到新市场，可能会添加新项目，因此要求列表是“动态的”。
在客户端 UI 之一中编辑客户记录时，我需要在下拉列表中显示区域列表，其中包含与客户域对象的区域属性关联的所选项目。
我可以处理它的 UI 方面，但模糊了如何在我的域层中获取和维护区域列表。我是否有单独的 RegionRepository 或者应该从 CustomerRespository 检索列表？如果客户是引用值对象的唯一实体怎么办？如果多个实体引用了 VO，这会改变方法吗？
实际上，我有许多此类查找，并且不想为每个查找创建单独的存储库（和 Web 服务），除非建议这样做。我曾考虑过为 API 提供单一的查找服务，但在更好地掌握这条路线将产生的影响之前，我犹豫是否实施。
虽然列表项是“键控”的，但它们不符合具有自己身份的实体的定义，并且除了父域对象（在本例中为客户）的上下文中之外，它们不存在。所以我假设它们是值对象，这很好。但是，我再次不清楚应该如何构建我的应用程序，以允许客户检索我上面描述的场景的 VO 列表。
I need some tangible guidance on implementing list of value objects in my distributed DDD application. Here's what I have:
My application is based on a RESTful service application running on a server providing services to several client applications. One of my entities, Customer, has a Region property that contains a reference to one of many Region value types. The list of Regions is stored in the back-end database but we do NOT provide an interface to maintain this list. Any changes will be made directly in the database (since it will be so infrequent) and will most likely be name changes and not add/removes. On occassion, like expansion into a new market, a new item could be added, thus the requirement for the list to be 'dynamic'.
When editing a Customer record in one of the client UIs, I need to display the list of Regions in a drop-down list with the selected item associated with the Customer domain object's Region property.
I can handle the UI side of it but am fuzzy how the list of Regions should be obtained and maintained in my domain layer. Do I have a separate RegionRepository or should the list be retrieved from the CustomerRespository? What if Customer was the only entity that referenced the Value Object? If multiple entities referenced the VO, would that change the approach?
I actually have many of these types of lookups and don't want to create a separate repository (and web service) for each unless it's recommended. I've thought about a single Lookup service for the API, but hesitate to implement until I have a better grasp of the impact this route will have.
While the list items are 'keyed', they don't fit the definition of an entity with their own identity and they don't exist except in the context of the parent domain object (in this case, Customer). So I'm assuming they are Value Objects, which is fine. But, again, I am unclear how I should structure my app to allow clients to retrieve the list of VOs for a scenario like what I described above.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以将它们放置在任何有意义的地方。您选择公开属性并实现存储库的位置不会违反 DDD 的任何约定。
作为一个例子，我使用以下内容：
都是
在我的例子中，这两个 由 ILookupRepository 实现的，因为这就是特定后端系统的设计方式。然而，在我们的另一个系统中，我们有一个实际的 ICountryRepository，因为后端和服务都与上述系统不同，并且它对于该场景更有意义。
You can place them anywhere that makes sense. Where you choose to expose the property and implement the repository isn't going to break any covenant of DDD.
As an example I use the following:
and I also have
In my case both of these get implemented by an ILookupRepository simply because that's how that particular backend system is designed. Yet in another one of our systems we have an actual ICountryRepository because both the backend and services are different from the above system and it makes more sense for that scenario.
我发现这个问题的关键是退后一步并评估查找列表实际存在的上下文。例如，区域列表可能是销售区域、地理区域等。识别这一点通常会引导我找到另一个上下文对象，其中该列表作为子项存在。
I found the key to this problem was taking a step back and assessing what context the lookup list actually exists. For instance, a list of Regions may be sales territories, geographical regions, etc. Identifying this has typically led me to another context object with the list existing as a child.