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.

Hi Michał,
thank you for you reply. I’d like to clarify a bit and hopefully come to a clearer ground for an answer I am seeking.

I agree completely with all the thing you’ve pointed out. There is not a magic formula to give us number of services or to draw us service boundaries. However, there is a practical side of things. I really like the DevOps principle, where devs are responsible for the code itself, the building, deployment and running the software in production. If you take this into account, then you have to think hard about the mapping that would be appropriate between the logical grouping of the ACs and the runtimes, because the runtimes should be owned by one single team - right? At least, that’s my premise.

Regarding this, I could have any number of services - say 3 which can have any number of ACs that are deployed into 3 runtimes, that are owned by 3 teams. So far, so good.


If my company is growing and I want to introduce another team, how should I reorganize then? Should I keep those three services regardless of the organizational change? Should I introduce at least another runtime? Should I even care about those things?

This is where it breaks down for me. The growth of the organization should also be supported by the architecture in such a way that every team has their own mission and responsibility. With services and ACs vaguely defined I don’t see the clear picture.

I mixed two different questions (this one and SOA Organizational aspects - who is responsible for the runtimes?) into one, because I think it is relevant. And under growth of the organization I mean rather rampant growth :slight_smile: Say 10 or 20 Teams for the same company that used to develop the software from one team upwards.

Hi Boško,

Yes but logically.

I understand the concept like this. Suppose that there is IT/OPS team responsible for technical things. The team decided that backend ACs could be host as Windows Services or Docker Containers. The team prepared recommendation and training how ACs should be deployed - for example by using one of the Deployment System. Suppose that I’m responsible for developing and maintenance the Shipping Service. Suppose that whole Shipping backend functionality required 40 ACs deployed in 10 Windows Services (the frontend functionality it’s another story). Now I’m responsible for ACs implementation, performance, etc. The IT/OPS team is responsible for runtimes monitoring, patches operating system, etc. The same division could be for Sales Service and Billing Service and other defined Services. Each Service could have the own machines for deploying their Windows Services so physically there is separation but logically the IT/OPS team owned all of them.

Off course if there is no IT/OPS team then like you said each Service team could do whatever they want.

I think in the first place you should try to recognize new logical Services and then decided if there is need for separate team for each new Service. For example suppose that you have to implement Loyalty Program. It sounds like a something different from Sales, Billing and Shipping so it’s good candidate for new logical Service. At the beginning it could be very simple functionality so there is no need for separate team. Suppose that the team owned the Sales Service start implement Loyalty Program. After some time there could be more and more requirements (workaround ;)) so in the Sales product backlog there will be challenge with prioritizing work to do. This is the good sign to introduce separate team for Loyalty Program.

I think the SOA architectural style has the clear picture of responsibility but like I said in the previous comment finding service boundaries is a challenge.

Hope this help.