问题标签 [bounded-contexts]

在我们的项目中，我们正在尝试应用限界上下文思想，但我们面临着一种明显的性能问题。例如，我们有不同的类（在不同的上下文中）来表示系统中的用户：Person在我们的核心域上下文和User安全上下文中。因此，我们为每个聚合有两个不同的存储库，但它们使用 DB 中的同一个表，有时访问相同的数据。

在这种情况下，是否有最小化数据库往返的通用解决方案？是否有处理它的 ORM，或者我们应该自己编写一些缓存系统？

upd：数据库来自旧版应用程序，我们必须“按原样”使用它

在我第一次涉足系统集成时，我确定了以下限界上下文：

1. 发票
2. 订阅
3. 收藏品

特别是对于集合有界上下文“暂停过期帐户”功能，我们将：

1. 从 Invoicing 获取过期发票列表
2. 向用户发送暂停通知（内部电子邮件服务）
3. 将请求暂停发送到订阅有界上下文

我了解如何使用阻塞 Web 服务来集成有界上下文，但我可以看到这会在远程服务关闭时带来问题。

我知道消息总线，但不确定我们将如何与消息策略集成：

每个上下文是否包含外部有界上下文的本地读取模型（在外部有界上下文添加/删除实体并通过唯一 ID 关联时监听来自外部有界上下文的事件）？

如果使用消息，我们是否真的从感兴趣的远程上下文构建实体的本地副本（具有用于本地上下文的字段）？还是我错过了其他东西？

我在域中几乎没有不同的限界上下文。CRUD 操作的验证建立在每个有界上下文中。

例如，只有当创建它的人是 Group Leader 时，我才能创建一个名为 GAME 的实体。

在此示例中，我有两个限界上下文 (BC)。一个是Game BC，另一个是User BC。为了解决这个问题，在Game BC中，我必须在继续创建游戏之前对User BC进行域服务调用，例如IsGroupLeader() 。

我不认为 DDD 推荐这种类型的通信。我也可以在Game BC中有一个User 实体，但我不想这样做，因为相同的User 实体在不同的 BC 的不同上下文中的使用方式不同。

我的问题是：

1. 我应该使用游戏 BC必须向用户 BC发送事件询问用户状态的域事件吗？使用这种方法，我不会像IsGroupLeader那样进行同步调用，而是调用is_group_leader的事件。然后 Game BC 必须等待 User BC 处理事件并返回状态。Game BC 只有在 User BC 处理完事件后才会创建 Game 实体。

2. CQRS 能解决我的问题吗？

任何想法表示赞赏。

我有一个 WinForms 应用程序，我希望将其重构为使用 DDD 架构。首先，我试图真正围绕架构本身进行思考，我有 Evans 的书和 Vernon 的书，我发现自己在努力应对我在应用程序中会立即面临的三个场景。我担心我在概念设计过程中可能会过度思考或过于严格。

1.) 利用 DDD 的 Pluralsight 教程中提供的示例，演讲者指出不同的有界上下文应该由他们自己的解决方案来表示。但是，如果我有一个不是面向服务的 winforms 应用程序（这最终会改变并且很多这个问题变得没有实际意义），这似乎不可行。因此，我在假设我将把这些分成不同的项目/命名空间时保持警惕，没有相互依赖关系。这是思考它的正确方法还是我错过了一些明显的东西？

2.) 我有一个导航 UI，可以启动其他模块/窗口，这些模块/窗口属于不同有界上下文的单独表示层。想想当您启动 ERP 应用程序时打开的第一个窗口。由于这不完全适合任何特定的 BC，因此如何正确实施这样的事情。这应该属于共享内核吗？

3.) 我有一个 Job Management 有界上下文和一个 Rating/Costing 有界上下文。这是业务流程的一部分，当创建作业时，它的详细信息会被评级。它有自己的 UI 等，我觉得这个演示文稿仍然充分地落在作业管理上下文中。但是，这些细节的实际评级过程绝对不应该。我不完全确定如何与评级/成本上下文进行沟通，因为 bc 将彼此分开。我意识到我可以发送消息，但这对于非分布式应用程序来说似乎有点过头了。每个 BC 都可以自行托管某种 API 是可行的，但这似乎有点过头了，尽管这可以很好地为团队稍后迁移到分布式架构做好准备。最后，我的最后一个想法是拥有某种共享依赖关系，它是一种事件存储。我不知道这是否与领域事件相同，因为这些事件本身似乎有一个单独的关注点。那么，这是否意味着这也属于共享内核或其他类型的解决方案？

先感谢您。

我正在开发一个非常大的应用程序，其中包含 100 多个模块和数据库中的近 500 个表。我们正在使用 Entity Framework 4.2 Code First 将此应用程序转换为 WPF/WCF。我们的数据库是 SQL Anywhere 11。由于数据库的大小，我们使用类似于 Bounded DbContexts 的方法，如Julie Lerman 的http://msdn.microsoft.com/en-us/magazine/jj883952.aspx所述. 我们的每个模块都创建自己的 DbContext，只对它需要的数据库子集进行建模。

但是，我们在创建 DbContexts 的方式上遇到了一个严重的问题。我们的模块不是完全独立的，也不是。有些包含从其他几个模块调用的操作。当它们存在时，它们需要参与调用模块启动的事务。（而且由于架构的原因，DTC 对我们来说不是一个选项。）在我们旧的 ADO 架构中，在模块之间传递开放连接以支持事务是没有问题的。

我查看了各种 DbContext 构造函数重载，并尝试从 EntityConnection 与 StoreConnection 管理事务，据我所知，没有任何组合可以允许 ModuleA 开始事务、调用 ModuleB 中的函数并拥有ModuleB 的 DbContext 参与事务。

它归结为两个简单的事情：

Case 1. 如果我用 DbContextA 的 EntityConnection 构建 DbContextB，则 DbContextB 不是用自己的模型元数据构建的；它重用 DbContextA 的元数据。由于上下文具有不同的 DbSet 集合，因此所有 ModuleB 的查询都会失败。（实体类型不是当前上下文的一部分。）

案例 2。如果我使用 ModuleA 的 StoreConnection 构造 DbContextB，DbContextB 无法识别 StoreConnection 在 EntityConnection 级别的打开事务，因此 EF 在 ModuleB 调用 SaveChanges() 时尝试启动新事务。由于数据库连接实际上有一个打开的事务，这会产生一个数据库异常。（连接不支持并行事务。）

有没有办法 1) 在案例 1 中强制 DbContextB 构建自己的模型，或者 2) 在案例 2 中让 DbContextB 的 ObjectContext 尊重其 StoreConnection 的事务状态？

（顺便说一句，我在 EF6 alpha 中看到了一些令人鼓舞的事情，但经过测试，发现唯一的区别是我可以在打开的连接上创建 DbContextB。但即便如此，上述 2 个问题仍然存在。）

我听说限界上下文概念与 DDD 密切合作，并且我看到了它与遵循代码优先方法的应用程序一起工作的示例。有界上下文是否也适用于 DB first 方法？我认为它会但没有看到很多例子。所以，请指导我。

谢谢

我找到了这个代码示例。

https://code.google.com/p/ddd-cqrs-sample/

看起来非常完整且组织良好。不是“框架”，只是一个具有非常精细和明确的做事方式的示例项目。但是，不完整。这带来了一些疑问。

他们擅长回答你的问题。在https://groups.google.com/forum/#!forum/ddd-cqrs-sample查看他们的 google 组

好的。问题是他们在 SALES BC 中有客户，在 CRM BC 中有客户/潜在客户。我想我们都同意指向同一个“人”。假设在销售漏斗中，此人从销售线索开始，然后通过购买使他成为客户的东西成为客户。

我的问题是，为什么他们对同一个“人”有三个不同的表示？它不能像“共享内核聚合”吗？我不知道这样的事情是否存在。在数据库 Client/Customer/Leads 中有三个表用于相同的“事物”，这让我有点困扰。另外，在示例中不清楚（未实施 CRM）您如何在 BC 之间进行通信。我阅读了他们的文档，但找不到任何有价值的线索。

那过程会怎样？假设您需要将此潜在客户/客户/客户添加一个地址来运送订单。你会选择哪一个？我猜是 Shipping BC 中的 ShippingAddress 吗？用 Id 指向？顾客？客户？您是否应该将地址直接添加到客户？以直邮为例，因为它与航运无关？

我搜索了很多关于有界上下文的信息，我知道这是领域驱动设计中的一种模式，它用于使用数据库上下文将我们的大型模型划分为更小的模型，但这让我有点困惑。事实上我不知道它到底是做什么的？以及使用这种模式有什么好处
请帮助我理解这种模式。

我正在努力在 Entity Framework Code First 中实现多个数据库上下文。如图所示，我已经实现了三个上下文（所有实体、与会议相关的实体和与用户配置文件相关的实体）。

Fluent API 用于实体映射。例如，这是用于 ConferenceContext 的代码：

谁能帮我创建类似于下图所示的上下文。

我已经设置了一个使用 ORM 填充的域项目。域包含不同的聚合，每个聚合都有自己的根对象。我的问题是应该如何处理跨越聚合边界的属性？

• 这些属性是否应该简单地忽略边界，以便有界上下文 A 中的域对象引用上下文 B 中的对象？
• 或者，是否应该没有从上下文 A 到 B 的直接链接，并且上下文 A 中的对象是否具有“int ContextBId”属性，可用于通过 B 聚合根从 B 获取域对象？
• 或者 ...

示例：
上下文 A = 用户
上下文 B = 游戏

在Users上下文中有一个对象UserOwnedGames。该对象具有一个属性，该属性User是对同一Users上下文中对象的引用。该对象还具有 a 的属性，该属性Game显然不在用户中，而是在Games上下文中。

这种关系会（或应该？）如何？数据库中很清楚（即 2 个外键），但代码应该是什么样子？