Why Service Oriented Architecture?

When we go about designing and building a scalable durable system we need to solve the number one issue: coupling. Implementing SOA also refereed to lately as micro-services will help you solve this problem.

In this talk, I will try to explain the Service Oriented Architecture’s paradigm…

Software design is hard, maybe the hardest part of building software systems… When designing distributed systems things get even more challenging. Now that Microservices are so popular, we all want to decompose our monoliths to smaller units of independent components. If we don’t want to end up with a distributed monolith, we need to have a toolbox of design concepts so we can achieve well-defined boundaries between our components groups described as “Services” and “Service Boundaries” in the Service Oriented Architecture or SOA paradigm.

The traditional way of designing systems based on a domain data model with very complex relationships and dependencies may kind of work when building a monolith, but just breaks apart when you building distributed systems.

One of the pillars of distributed system design is to solve the coupling problem.

If we look at the tenants of SOA they all address coupling:

• Explicit Boundaries: In it’s simplest form it is to find what belongs together and making sure there are no leakages between the defined boundaries of a “Service”.
• Autonomy: Like in Object orientation, Keep our components and “Services” autonomous, encapsulated and have as little dependencies to the outside as possible.
• Sharing schema and contracts not classes: Make sure we don’t introduce coupling by using an open protocol for communication.
• Compatibility based upon policy: This is the hardest tenant to articulate, but again, it’s about loos coupling, an explicit API that describes the component’s behaviour.

In order to achieve this, we need to rethink how we design our components and “Services” We need to move from monolith thinking to distributed thinking, leaving the single relational data model to multiple vertical bounded contexts that together compose a “Service” boundary.

Build stuff Nov 2017: SOA lessons learnt (OR Microservices done better)

Vox Vienna June 2017: SOA lessons learnt (OR Microservices done better)