问题标签 [bounded-contexts]

在我的域中，我有两个有界上下文，一个包含员工，另一个 BC 是电子邮件通信器，我的员工只有在获得批准后才会获得密码，因此此时会向他们发布密码。

这个密码是加密的，所以我想用新的加密密码联系包含员工的 BC，但还要在另一个 BC 中向他们发送一封电子邮件，其中包含一封包含他们的用户名和密码的欢迎电子邮件。

我考虑过为此使用事件，发送一个事件来更新 Employee 实体，另一个发送电子邮件。

这是最好的方法还是有人知道更好的方法？

提前致谢

我正在将不同的有界上下文与 Windows 服务总线集成并有一些问题：

1）如何在其他有界上下文中检测重复？存储最后处理的消息序列？我希望能够重新触发事件以允许重新同步新的有界上下文HandleEvent(OrderPlaced orderPlaced, bool isReplay)，这些上下文在未来被购买到生产中以进行初始同步。

2) 对于上下文间消息总线，我们是否会为每个有界上下文使用一个主题（并使用命名空间来对有界上下文进行分组）？还是每个命名空间有一个有界上下文？

3）消息总线文档说消息可以乱序到达，应该使用什么算法来按顺序重新组装？如果收到了消息 6 和 8，但没有收到消息 7，会发生什么？我们会等待指定的时间，然后继续吗？如何允许自我修复？

4）我想以上在几乎所有 DDD 项目中都很常见，是否有任何库可以处理包括命令/响应协议在内的消息传递，以从外部有界上下文请求同步先前事件？

恕我直言，最出色的 DDD 概念之一是应用程序中分离上下文的能力。但是我对如何将所有东西放在一起感到困惑。

首先，我知道一件事与另一件事无关。但我的问题正好落在基础设施/ORM 部分。

例如，我有一个名为Procedure（医疗程序）的域对象。在注册的上下文中，唯一重要的是代码和名称。但是在Procedure Management Context中，我有很多其他领域，比如Price属于这个特定的上下文。

如何使用 EF Code First 让两个具有不同属性的同名实体（在不同的上下文中）？基本上，我想将所有字段保存在同一个表中，但在一个上下文中只检索 2 个字段，而在另一个上下文中检索所有字段。我怎样才能做到这一点？

我正在尝试在个人项目中练习领域驱动设计。我有一个示例域，我试图在有界上下文中进行划分。

我几乎可以肯定我知道该怎么做，但是在定义了它们之后，我开始对它们感到不确定。

我怎么知道它们定义明确？我怎么能确定我是否做错了？

我试图弄清楚我如何处理 DDD 和有界上下文的使用。

我试图举一个例子来说明我的问题。（我正在使用贫血课程来提高速度）。

我正在尝试绘制出如何在不同的有界上下文中分离域对象。

我想到了可能是 Employee 的域对象。

假设我有两个有界上下文，人力资源部和财务部。

一般来说，财务部门比人力资源部门需要更多关于员工的信息。人力资源部门不需要任何与员工银行详细信息、国民保险号码或合同工时相关的信息。（也许在某些企业中这并不完全正确，但让我们在示例中假设这一点）。

因此，在两个不同的上下文中，与 Employee 所需的行为/交互是不同的。

人事部。

财务部门。

鉴于此示例，我如何限制 HR 上下文中的 Employee 对象，使其仅具有所需的行为，并且财务上下文具有扩展行为。

如果应用程序被分解为多个上下文，所有上下文都具有与 Employee 关联的自定义行为，我将如何为 Employee 对象建模。

我已经研究了构建上下文映射的不同方法，共享内核似乎很有希望，但这意味着所有上下文将共享与 Employee Domain 对象关联的所有行为。

我希望每个上下文都是有限的。

帮助！

这是我第一次将 DDD 概念应用于现实世界的问题。

由于项目相对较小，我只从 1 个有界上下文开始。然而，我发现自己拥有几乎相同的类，即非常相似的名称、非常相似的属性但不同的行为。我开始认为它们实际上属于不同的有界上下文，因为实体是相同的，只是在不同的上下文中具有不同的含义。应用程序基本上有两个完全不同的用户组这一事实支持了这一点。

我已经阅读了一些关于不同限界上下文中的两个实体如何相互通信的内容。我想我理解这个概念......但不知道如何实施？某处有.net示例吗？即一个有界上下文中的聚合根将事件发布到另一个有界上下文中的聚合根？以及在另一个有界上下文中调用聚合根的聚合根。

每个有界上下文都应该有自己的：服务层吗？存储库和数据层？

我们正在编写一个 MVC 数据维护应用程序是一个更大项目的一部分。我们尝试使用领域驱动设计 DDD。在 SO 上已经有其他关于此的问题，例如这里、这里和这里。然而他们并没有完全回答我的问题。

由于数据库有 75​​5 个表，因此我们在数据层中也有有界上下文。因此，我们为业务、角色、产品、客户等创建了有界上下文。

我们遇到的问题是，在 MVC 应用程序中，我们有一个“初始设置”视图，它使用最终跨越多个有界上下文的 ViewModel（在 Entity Framework 6 中使用 IUnitOfWork 模式）。因此，该视图必须写入业务上下文和角色上下文。

域模型将在一个更大的 pbject 图中有一个Business模型和一个Address模型以及一些其他模型。

ViewModel是这两个和其他领域模型的扁平化简化模型：

这个 ViewModel 应该映射到我们正在使用Automapper执行的域模型。

控制器获取注入的域服务：

问题：

1. 服务无法知道InitialSetupViewModel，那么应该将什么传递给服务？

2. 服务必须知道BusinessDbContextand RolesDbContext。所以我必须在两者上调用 SaveChanges()，这超出了拥有单个 IUnitOfWork 的目的。我是否必须创建另一个包含业务和角色实体的 UnitOfWork？

我认为将这两个 IUnitOfWorks 合并为一个只是为了使这个 MVC 视图工作是不合理的。但是解决方案是什么？

谢谢！

我看过 Julie Lerman 关于在企业应用程序中使用 EF 的视频。现在我正在开发一个使用“有界上下文”和她在该系列中教授的其他内容的网站。

问题是我不知道如何在我的“业务层”中使用有界上下文 (BC)。更清楚地说：BL 应该如何知道它应该使用哪个特定的 BC。

假设 UI 从业务层请求产品列表。在 BL 中，我有一个返回产品列表的方法：GetAll(). 此方法不知道 UI 的哪个部分（站点管理员、版主或公共用户）请求了产品列表。由于每个用户/场景都有自己的有界上下文，因此需要使用该相关上下文来拉取列表。BL应该如何选择合适的BC？

此外，我不希望 UI 层与数据层交互。

如何才能做到这一点？

我一直在阅读有关 DDD 和有界上下文的信息，但我认为我的想法是错误的。起初，我喜欢子域和限界上下文的想法，我是这样理解的：有一个软件要开发，但是一次攻击太多了，所以我们把它分成逻辑部分，一次开发。我们解决的另一个问题是普遍存在的语言的歧义。

这使我将有界上下文视为基本上只是我对与应用程序的某些特定部分相关的代码进行分组和绑定的文件夹。我认为这段代码是由类似的东西组成的

• 该有界上下文的域模型，包括存储库和服务的抽象
• 有界上下文的基础设施层、存储库的实现等

当然，域模型和基础设施在有界上下文中正确分离。

然而，进一步阅读，似乎每个有界上下文本身就是一个完整的应用程序。例如，有时似乎每个有界上下文都有自己的应用程序层。

这让我很困惑，因为有时我不想最终开发大量的应用程序，我只是开发一个。应用程序的限界上下文划分应该是构建一个应用程序，而不是很多应用程序需要集成。

我似乎在@MikeSW 说OP 提出的两种方法都有效的地方提出了这个问题。我要问的是第三种结构：

至少对于我所看到的所有应用程序来说，这更有意义。我想要一个应用程序，而不是几个具有多个演示文稿的应用程序，但我仍然希望能够打破诸如“限制无处不在的语言”之类的领域和利益。

那么，有界上下文是一个完整的应用程序吗？还是可以像我理解的那样使用有界上下文并感觉更有用？我的方法有什么问题吗？

我正在努力理解如何为我的问题建模：

• 一个公司可以有多个团队。
• 每个团队必须有每个公司的唯一名称。
• 特定团队的报告以及公司所有报告的列表必须是可检索的。

刚才，我有 3 个限界上下文 - 公司、团队和报告。我相信我应该将 Team 移入 Company 以强制执行我的唯一名称不变 - 但是，据我了解：

“聚合边界之外的任何东西都不能包含对内部任何东西的引用，除了根实体”。

如果我只能从我的报告 AR 中引用一个 AR，我就无法存储我的报告属于哪个团队 - 只是公司。

我认为团队可能作为它自己的 BC 存在，也可能存在于公司 BC 中。团队的创建只能在 BC 公司内部作为一个实体进行。在这里，可以确保该团队名称的命名和不变实施。然后，团队 BC 将仍然存在，并且报告仍然可以保留对来自报告 AR 的 TeamId 的引用。但是，这将导致 TeamId 和 TeamName 重复 - 在 Company BC 和 Team BC 内。

这种方法听起来不错，还是我错过了什么？

如果我有 3 个 BC 应该是 2 个 BC，或者在公司 BC 中缺少团队实体概念，我会感到困惑。

也许我混淆了我只有/需要聚合根的有界上下文 - 我不确定！

咕噜，救命！