This is not a topic about nservicebus but rather about the Service Oriented Architecture and the Advanced Distributed System Design course. In the course Udi Dahan spoke about Services a lot and one thing caught my attention more than others, because I find this very opinionated across the internet.
The question is, how big should a service be? Or rather, how many services does a distributed architecture have.
I find this question very interesting, because it has multiple dimensions to it. Let’s start with the service definition Udi is using:
“A service is the technical authority for a specific business capability.”
So the first dimension would be drawn from the business domain. That should be obvious in the SOA world (although maybe not ubiquitous).
The second dimension would be the maintainability of the technical authority. How big is too big?
The third dimension would be the size of the organization. I find it hard to grasp the same granularity for two teams and 22 teams developing a distributed architecture.
There is more, but these are the most prominent in my view. Udi said in the ADSD course, that in his experience, there should usually be 7-15 Services with 1-2 Business Components and as many Autonomous Components as we like.
It seems from this view that number of services is irrelevant and that the size of the distributed system is determined by the number of Autonomous Components.
Any thoughts about this?