Granularity and SOA

First of all let's agree on (or at least assume) that services are great for crossing borders, such as platform borders and/or company borders.

But what about the internal structure of such a service? Should it be built of several smaller services? For a while now Iíve been trying to get a sense of what the heavy SOA people think about the granularity of services, without luck. When reading some texts, you might get the impression that the services should be extremely fine grained, which I have a problem agreeing with.

The keyword above was "extremely". If you decide to go the route of creating extremely fine grained services you should note that it will carry a cost which could potentially be very high. For example, you can't and shouldn't use physical database transactions spanning several services. Sure, you can use compensating solutions instead, but this adds complexity where you might not need it. (Another reason why services should not be broken down to the extreme is the added communication overhead.)

The result you get when breaking down the services is that borders are added within your services. Believe it or not, those borders not only have benefits, they also have costs.

Damn, it seems to be a matter of tradeoffs as usual. A rule of thumb like "always do it like this" might be hard to find.