A familiar example of loose coupling from within your organisation

We know that loose coupling is a good thing, Whether you're building SOA services or microservices, you know that tight coupling between components leads to problems, not least in production, and especially as load increases. If we can reduce coupling we can reduce those problems or even resolve them completely, but how do we do it? How do you design components that work together to form a system, but yet don't depend on each other?

The first of the "Four tenets of service orientation" might help here. As Microsoft describes it:

"Service boundaries are explicit. Services are discrete units of operation. They perform one task and that task alone. Each service should be able to stand alone with no external dependencies on other services. This is what is meant by "loose coupling." "

But for me the explanation of this tenet is a bit extreme. If we create services that stand alone and share nothing, how do we expect them to combine to form a system that delivers business value? Our services need some level of coupling in order to function as a system, That's why we discuss loose coupled components rather than decoupled components.

At a recent Dublin Microservices Meetup, @Farmar presented a tale of SOA experience and wisdom that he feels we can't  afford forget. At the same meetup, @Stilkov presented a view that microservices must be useful and the UI must be a first class citizen in any architectural plan. Both talks contained versions of the same slide. Something like this:

Services as vertical slices through the tiers of the traditional architectural diagram.

But why does this help and how does it help achieve lose coupling? How does having encapsulated verticals result in loose coupling?

Stepping back to the real world, you (probably) work in a technical team for a company that has an HR department. Both Tech and HR have a contract with the business. The Tech teams' contract is that they'll deliver quality software to provide technical solutions to their customers. The HR department's contract is (let's say) that they'll recruit quality people to the business, deal with contracts, salaries and performance reviews.

Now consider the qualities of those teams. They are separate, they operate independently, capturing and storing their data separately, yet together, they form two elements of a system (the company). They are loosely coupled.

For example, if the Tech team is outsourced to Kiev, the operation of HR is not affected. Similarly,
if  HR changes their working hours to an overnight-shift, or they even go on vacation en-masse, the Tech team can still function.

At this level of systems design, the behaviours found in the business are a good match to the system behaviours that we're trying to create. Aligning our technical boundaries with the boundaries and behaviours found in the business can enable us to achieve the loose coupling that we've been chasing for the last decade.

@Farmar at Microservices Dublin

@Stilkov at Microservices Dublin

Four tenets of service orientation