实体配置管理与DDD有界的上下文 [英] Entity configuration management with DDD bounded contexts
问题描述
我正在尝试实现多个DDD有界的上下文，如 here <一>。这是一个示例上下文：
I'm trying to implement multiple DDD bounded contexts as outlined here. This is an example context:
我有一个实体类型配置文件，每个实体具有相应的FluentAPI映射（使用EF工具进行反向工程）。这些配置文件还包括关系配置。
I have an entity type configuration file for each entity with the appropriate FluentAPI mappings (reverse engineered using EF tooling). These configuration files also include the relationship configurations.
例如：UserMap.cs
// Relationships
this.HasOptional(t => t.SecurityProfile)
.WithMany(t => t.Users)
.HasForeignKey(t => t.SecurityProfileCode);
SecurityProfile 和在上下文中，DomainPermission 不是 DbSets 。由于用户和模块之间的导航属性，它们将自动进入模型。
SecurityProfile and DomainPermission are not DbSets in the context. They are automatically brought into the model due to the navigation properties on User and Module respectively.
这导致我的第一个问题。将 User （或任何其他实体）添加到任何其他上下文时，我必须记住要执行以下两项操作之一：
This causes my first issue. When adding User (or any other entity) to any other context I have to remember to do one of two things:
-
还将配置添加到模型构建器中
SecurityProfile（以及实体上的每个其他关系）
Also add the configuration to the model builder for
SecurityProfile(and every other relationship on the entity)
从模型中明确地排除 SecurityProfile 。
这开始变成一个维护噩梦。
This is starting to become a bit of a maintenance nightmare.
我会很满意，将实体图显式修剪在上面的第2点概述。
I would be satisfied to explicitly "trim" the entity graph as outlined in point 2 above.
然而，当关系已经存在时，似乎不可能忽略（）实体在实体配置文件中定义。
However it doesn't seem possible to Ignore() entities when relationships are already being defined in the entity configuration files.
为上述上下文尝试 modelBuilder.Ignore< SecurityProfile>（）; OnModelCreating 在 ConfigureAssociations（）中出现以下错误：
Trying modelBuilder.Ignore<SecurityProfile>(); for the above context OnModelCreating gives the following error in ConfigureAssociations():
System.InvalidOperationException：n avigation属性SecurityProfile不是User类型上声明的属性。验证它没有被明确排除在模型之外，并且它是一个有效的导航属性。
我想到的唯一解决方案是继承基本配置类，并覆盖每个上下文中的关系配置。考虑到我们可能会遇到30-40 +单独的上下文，这也可能成为一个维护噩梦。
The only solution I can think of is to inherit the base configuration classes and override the relationship configuration in each context. Considering we may end up with 30-40+ separate contexts this could also become a maintenance nightmare.
或者，我可以为每个上下文都有非常具体的实体模型，但是再次将导致实体类爆炸和重复配置中的潜在维护问题。
Alternatively I could have very specific entity models for each context, but again this would lead to entity class explosion and a potential maintenance problem in duplicated configuration.
在实现有界的上下文时，如何最好地管理和维护实体及其实体配置？
推荐答案
由于这段时间长久以来添加评论：
Added here due to a bit too long for comments:
有趣的是，您所指的文章显然是试图通过提到新的流行语 DDD 和随后仅显示DTO / POCO对象如何在上下文中持久化。这完全没有什么可做的DDD。
It is extremely (un?)funny to note that the article you are referring to is apparently trying to jump on a bandwagon by mentioning a new buzzword DDD and subsequently showing only how DTO/POCO objects can be persisted in a context. This has absolutely nothing to do DDD.
域驱动设计主要是针对行为和封装（基础设施隔离/无知）模型进行迭代探索和改进，以解决具体问题具体的演员，并在问题域的无处不在的语言中表达。
Domain Driven Design is primarily about behavior and encapsulated (infrastructure isolated/ignorant) models that are iteratively explored and refined to solve specific problems for specific actors and that are expressed in the ubiquitous language of the problem domain.
这些模型通常不会直接映射到某种类型的持久性模型，也不应该关注这一点。在有界环境中对聚合根执行的操作通常与事务边界一致。
These models typically do not map directly on some type of persistence model, nor should they be concerned with that. Operations performed on aggregate roots within a bounded context typically will align with transaction boundaries.
我建议您观看Eric Evan关于技能交流（关键字DDD交换）的网络广播为了得到正确的观点，DDD的含义是什么，有限的上下文和聚合根是什么。之后，你也真的应该读他的书，这是一个伟大的阅读。但是您需要他最近的观点（如这些网络广播中所表达的那样），不要陷入专注于技术构建的障碍。
I would advise you to watch some of Eric Evan's webcasts on skillsmatter (keyword DDD eXchange) in order to get the right perspective on what DDD entails, what bounded contexts and aggregate roots are. And after that you also really should read his book, it's a great read. But you need his more recent perspectives (as expressed in these webcasts), not to fall in the trap of focusing on technology building blocks.
这篇关于实体配置管理与DDD有界的上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
