有界上下文之间的通信

Question

我有一个WinForms应用程序,我希望将重构为使用DDD架构.首先,我试图真正地围绕建筑本身,我有埃文斯的书,我有弗农的书,我发现自己正在努力应对我将面临的三个场景.我担心在概念设计过程中我可能会过度思考或过于严格.

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

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

3.)我有一个工作管理有限的背景和评级/成本计算有限的背景.创建作业时,业务流程的一部分是对其详细信息进行评级.这有自己的UI等,我觉得这个演示文稿仍然充分属于作业管理环境.但是,这些细节的实际评级过程绝对不应该.我不完全确定如何与评级/成本核算相关联,因为bc要彼此分开.我意识到我可以做消息传递,但对于非分布式应用来说,这似乎有些过分.每个BC都可以自己托管某种API,但这似乎有点过分,尽管这会让团队很好地在以后迁移到分布式架构.最后,我的最后一个想法是拥有某种共享依赖,这是一种各种事件存储.我不知道这是否与Domain Events相同,因为它们本身似乎有一个单独的问题.那么,这是否意味着这将属于共享内核或其他类型的解决方案？

先感谢您.

Answer 1

1)关于与解决方案相对应的BC的指导只是指导,而不是硬性规则.但是,它确实提供了非常需要的隔离.您仍然可以使用WinForms项目.例如,假设您有一个名为Customers的BC.为它创建一个解决方案,并在其中创建一个名为Customers.Contracts的附加项目.该项目有效地容纳了BC的公共合同,其中包括DTO,命令和事件.外部BC应该只能使用此合同项目中定义的消息与Customers BC进行通信.让WinForms解决方案引用Customers.Contracts而不是Customers项目.

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

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