SOA

SOA, it’s the buzzword du jour (or de la d├ęcennie).

First, let’s take a look at a well designed system…

A Well Designed System

Now let’s take a look at the same system, but this time publishing the domains as services…

A Well Designed System with Services

What? Where are they? What changed? Where’s the service layer?

Breaking out the scanning electron microscope, let’s take a closer look…

Service Layer

Yes, if the system has been designed correctly, the service layer will be a wafer thin piece of code that takes an existing domain and makes it available as a service (i.e. accessible via REST, AJAX, SOAP, etc.).

Given what should be a paltry amount of code and the fairly formulaic methods for publishing and governing services, why such an emphasis on SOA? The bulk of the developers’ intellectual effort should be building out the domains and correspondingly the bulk of an architect’s time should be dedicated to the design of these domains (their decoupling and internal design). This is where, if not monitored, catastrophes can happen. Taking a domain and making it service is simple by comparison, so again, why such emphasis on SOA?

Leave a Comment