The Service Layer Pattern

One of the key ingredients in managing Enterprise software products is identifying and consistently applying a proven, battle-tested architecture. Without an over-arching architectural outline the end result of a constantly evolving product will likely be a sprawling, deeply-coupled codebase that’s brittle and hard to work with.

Of course, having an architectural plan is not enough. All your team members (or at least the senior devs) need to “buy in” and be settled on the rationale supporting the plan.

![Service Layer Pattern](/images/2016/02/service-layer.png)

When evaluating architectural frameworks I look for ones that facilitate…

  1. System Comprehension
  2. Modularity (Separation of Concerns)
  3. Testability (Explicit Dependencies)
  4. Hexagonality (Transport Agnosticism)
  5. Cross-cutting concerns
  6. Plugin-orientation
  7. Scalability

One of the Architectural patterns that I’ve found very useful in this regard is the Service Layer Pattern. I find that combining this with a couple of other design patterns gives me a lightweight yet robust architectural framework for large-scale applications.

Here are the steps I recommend:

The relevant Design Patterns are:

The Service layer then is all that your transport layer (HTTP Controller, CLI client etc) will know about and interact with, which results in a hexagonal or symmetric system.

One major (& often overlooked) advantage of a Service Layer is the ability to progressively split a monolithic codebase into a suite of micro-services (for scalability) with the least amount of effort.

There you have it: Modules, Commands, Events, Services and a Container together providing a layered and modular enterprise architecture framework.