CESARDELATORRE
commented
6 years ago Of course, and this is a very good question. Not a "poorly-formed or irrelevant question" at all. The point is that whatever is shared across microservices should be artifacts like "standard libraries", Nuget packages, "building blocks" that should be generic enough. It is like sharing a NuGet package for JSON serialization (i.e. Newton JSON serializer), or sharing a client API from Azure SDK in order to work with Azure Service Bus or API for Azure Storage Blobs, etc.
It has to be the kind of stuff you would create NuGet packages to be re-used across different applications and even different customers because it is a generic artifact that shouldn't be changing constantly as the application evolves. However, it is clear that a team needs to be responsible for those building blocks in the same way that a team is responsible for any public and published NuGet package or SDK.
On the other hand, you shouldn't share simple "common code" across microservices because that would impact their autonomy. But it is ok to share libraries or NuGet packages that are generic enough, meaning generic enough even for different applications or customers.
In a production project you would convert those building blocks to Nuget packages. We're not doing so because we want the community to explore that code, too.
About SPOF. Well, not really. In production you would use a scalable system like Azure Service Bus which is high available, so it is not a SPOF like a single RabbitMQ container that we use only for Dev/Test environments. You could also create a HA RabbitMQ environment, but that will be IaaS, more infrastructure complexity to make it high available and scalable. But that is an option, too.
I hope the differences are clear enough. And again, very good question because as a general rule, in microservices is more important to favor autonomy than just trying to re-use any kind of code. DRY must be taken with care across microservices. But this case, an Event Bus or any "public" NuGet package, are exceptions because those components should be generic.
MikahB
Apologies if this is a poorly-formed or irrelevant question, I'm working hard to understand Microservices architecture and it's foundations in DDD.
Based on what I'm reading, it seems like referencing the common EventBus and CommandBus projects from each microservice couples them more tightly than they should be and creates a SPOF. Is this just done in this example as one option, or is this how an enterprise-grade application should be built?
I understand the Buses themselves are common, but if someone tweaked those projects you could impact all services based on them. Maybe the buses being common overrides the need for separation here? Appreciate any insight into this small piece of a large puzzle.