事件订阅和源级耦合

Question

在服务边界之间创建pub / sub时，建议创建一个＆＃34; Messages＆＃34;或＆＃34;活动＆＃34;部件。发布者从该程序集发布事件（接口）。订户侦听该事件（接口），这意味着订户中至少有源级耦合到发布者服务边界中的程序集。

在具有大量发布/订阅事件的企业场景中，是否可以以订阅者可以收听和反序列化消息的方式发布事件，而无需引用发布者的消息程序集？这种方法的缺点是什么？

使用自动构建和这些共享程序集，如果团队发布了一个新事件（向共享程序集添加了一个接口），我不想订阅，我的服务将排队等待构建。这导致了不必要的工作和潜在的混淆，为什么我的项目重建，我的团队不需要采取任何行动（除了调查并发现没有采取任何行动）。

这是一个基本的DotNetFiddle Example，说明了我要解释的内容。本质上，我试图避免从Quoting.Backend.dll中对Purchasing.Events.dll的项目/程序集引用。

Answer 1

four tenets of SOA的第三个原则是“服务共享架构和合同，而不是类”，但事实证明交换这些架构和合同的最简单方法是通过类，以免我们进入WSDL就像我们使用基于SOAP的Web服务一样。

所以，是的，如果你滥用契约表示为类的实现细节，并且拥有引用所有消息程序集的大型单一解决方案，那么你将得到你描述的所有问题。

解决方案是更加关注其他两个原则：边界是明确的（＃1），服务是自治的（＃2）。

这是什么意思？

• 特别是在您描述的大型企业场景中，每个服务都应该在自己的解决方案中实现。
• 每个服务都应该发布自己的事件程序集，其中包含服务所拥有的事件，通常称为ServiceName.Events.dll或ServiceName.Contracts.dll
  • 只应包含事件类（架构）。服务内部没有命令。事实上，根本没有命令，因为自治服务应该只通过事件进行通信。
  • 私有NuGet服务器（或MyGet之类的服务）对于此程序集的分发是最佳的。
• 每个服务的事件都应该非常明确地进行版本控制，最好严格遵守SemVer的规则。

如果您遵循这些准则，当团队发布您不想要/不需要订阅的新事件时，则无需进行任何更改。它会继续运行。您可以关注NuGet存储库，并就何时以及如何升级其他服务的事件程序集做出明智的决定。