【发布时间】：2015-04-01 14:59:36
【问题描述】：
我已经应用了域驱动设计的多界上下文原则，并且有 3 个不同的对象（在 3 个不同的域上下文中）指向数据库中的同一个表。正如 julie lerman 建议的那样，我有一个共享数据库模型，其中包含我的所有对象。此共享数据库模型用于代码优先迁移。我也有流畅的 api 配置，代表共享数据库模型上的外键关系和列约束。问题是，我是否应该让我的 3 个特定领域的上下文知道这些流畅的 api 配置。我想在每个上下文中验证我的对象图。我是否应该担心这些单独的域上下文中的字符串长度、所需等等？在 3 个单独的域上下文中的每一个上配置这些关系是否有必要/良好做法？
【问题讨论】：
-
“让上下文知道”是什么意思？ Fluent 映射在 DbContext 中定义，而 DbContext 又可能在概念上与您的域中的有界上下文相匹配。 3 个不同的域类 = 每个有界上下文中的一个 = 3 个 DbContext 中的每个中的一个映射。
-
举个例子会更好。让我试着在这里给一个。假设我们有一个客户，他已经下了一些订单。假设我们有一个客户管理域和一个订单管理域。客户的属性是名称和地址。我在这里有 2 个单独的有界上下文。订单管理域也有一个客户对象，但只有 Id、Name。订单管理域不关心客户的任何其他属性。现在我有一个通用域，所以我可以先将代码迁移到数据库。这个通用上下文具有来自所有对象的所有属性。
-
如果来自 fluent API 我说名称不能超过 100 个字符。所以数据库仅限于这些字符，我是否应该在客户管理域上下文中重复相同的内容。我认为这是对客户对象进行验证的方式。如果在较小的有界上下文上重复我的“规则”是一种方式，我是否还应该在较小的域上下文中包含其他流畅的 api 配置（如外键等）。
-
如果您指的是 Julie Lerman 所说的“超级上下文”（在您的原始 Q 中并不清楚），那么我想关系定义也应该出现在重点上下文级别，否则，当您查询重点 DbContext 时，EF 怎么能够连接您的导航属性以及所有这些？
-
经过几周的努力，我可以确认之前的评论是正确的。鉴于拥有多个域的多边界上下文需要大量工作，我希望这一切都是值得的。
标签： entity-framework domain-driven-design bounded-contexts