winforms - 限界上下文之间的通信

Question

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

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

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

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

先感谢您。

Answer 1

1)解决方案对应的BCs的指导只是指导，不是硬性规定。但是，它确实提供了急需的隔离。您仍然可以在 WinForms 项目中使用它。例如，假设您有一个名为 Customers 的 BC。为它创建一个解决方案，并在其中创建一个名为 Customers.Contracts 的附加项目。该项目有效地包含了 BC 的公共(public)契约(Contract)，其中包括 DTO、命令和事件。外部 BC 应该能够仅使用此契约(Contract)项目中定义的消息与客户 BC 进行通信。让 WinForms 解决方案引用 Customers.Contracts 而不是 Customers 项目。

2) UI 通常充当组合角色，编排许多 BC - 复合 UI。一个典型的例子是亚马逊产品页面。呈现页面需要来自不同 BC 的数百个服务。

3) 这似乎又是一个需要复合 UI 的场景。表示层可以在不同的 BC 之间进行调解。 BC 是松耦合的，但 BC 之间仍然存在关系。有些是其他人的下游，有些是上游，甚至两者兼而有之。每个都有一个反腐败层，一个端口，用于与相关的 BC 集成。