SOA Service granularity

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?

Hi Boško,

Finding service boundaries is a challenge and there is no such a “give me requirements and I tell you how many services will be enough and each of them should have this kind of size”. As you wrote there are many variables that have to be take to consideration. As presented in the exercises in the course one option could be start drawing solution and trying grouping things together. Sometimes it’s obvious for example Finance should be as much independent as possible from Shipping but sometimes it’s not so clear. To make a decision sometimes helps to think extremely defense:

“if I turn off this technical part will other parts be work correctly?”

for example

“if I turn off everything from Shipping will orders still be accepted and will credit card checking still be working?”

From the business point of view this two parts could be separated (separate services) so the technical solution should follow the same rules.

The Service is a logical concept. The Autonomous Component (AC) is a physical concept. AC’s are grouping together within Services. Without logical grouping there is much more chance to create strong dependencies between AC’s which shouldn’t be.

Summarizing I think the question What is the size of the Distributed System (DS)? could be extended by questions:

  • How hard is to implement new requirement in the DS?
  • How hard is to extend existing functionality in the DS?
  • How hard is to replaced existing functionality in the DS?
  • How hard …?

Hope this help.