Monday, April 21, 2008

Service Granularity

Two key outcomes that we aim for in the design of software systems are high cohesion and loose coupling. Cohesion is the degree to which the concerns within a single software component are related. Coupling on the other hand is the measure of interdependency between software components.

We have discussed many strategies for reducing coupling between services in the past. Examples include decentralising your data, using process centric interfaces, using asynchronous messaging, using document-centric messaging, and avoiding command messages. Furthermore, SOA as a style of architecture promotes loose coupling through the use of service contracts that encapsulate the implementation details of a service behind its boundary.

However one of the largest determining factors of coupling is in fact the level of cohesion found within services.

One way of looking at cohesion is how precise a domain model is at expressing the problem domain. If the domain model contains ambiguities such that definitions become confused, then we have low cohesion. Where we start to lose cohesion with a domain model we look at subdividing the model, which Eric Evans makes reference to with his Bounded Context pattern.

We will then likely have the same entity (e.g. a customer entity) represented in both models, but the representations will see the entity from different points of view, optimised for the subdivided domain model. So for example, we may have Sales and Billing domain models - both involving a customer entity, but seeing it from different perspectives. This would result in a different data structure in both models with different business logic, but both pertaining to the same customer entity.

In SOA terms, when we see the concerns of one service becoming ambiguous and confused, we look at subdividing it into two or more services such that the domain models of each service have high cohesion again. If done correctly, we will find that the new services will also have loose coupling between them, as the concerns between services will be only loosely related.

If we subdivide too far, we will find that information models and business logic become duplicated between services as the relative difference in definition of the same entity between domain models becomes increasingly similar.

So there is a delicate balance with regards to service granularity such that we get the right mix of cohesion and coupling.

There is no magic formula for service granularity. It is simply a matter of iteratively refining your architecture until you have sufficient loose coupling and high cohesion. Where you start seeing the need for synchronous request-reply interactions between services, cross service transactions, CRUD interfaces and duplication of logic and data representation between services, you have subdivided too far and must start combining services.

Where you start seeing confused representations of entities in the domain model of your service, you have not subdivided far enough.


Fredrik said...

That's a great description of cohesion and coupling, and how they are related (which I find people often don't get). Enjoying your blog, keep it up :)

Bill said...

Thanks! Always great to get positive feedback! :-)

badis said...

Hi, I came across your blog while looking for good articles on how to leverage existing applications and expose selected functions as services. I've read some of your articles and I think they are great. I am new to SOA and I work for a group who owns 5 different large web applications. These applications, although, all Java-based, use different technologies. Some are implemented with EJB, others with Spring or home grown frameworks. What is the least-invasive approach to expose these functions as services in your experience.


Bill said...

Hi Badis,

First let me say thanks for you kind words regarding the blog. :-)

I have answered your question as a separate blog post you can find here.

Fawad Tariq said...

Dealer's Choice provides various services to the automotive industry that are designed to make the business process more efficient and streamlinedService ContractsOur mission is to reduce the cost of operations for dealerships and increase their productivity with tools that give customer satisfaction a new meaning...

Ramona said...

This is gorgeous!