Skip to content

Clojure Microservicesλ︎

Clojure Microservices are an architectural design approach, with advantages and constraints.

Domain Driven Design (DDD) princilples are relevant to microservice design.

Effective testing is essential to avoid regressions and help ensure a consistent API across all services. Changes should be additional rather than breaking where ever possible.

Aspects of a Microservice

A microservice is a natural concequence of applying the single responsibility princilple at the architecture level

A microservice typicaly has its own data store, persistence layer or connection to an event stream

A microservice should to be loosley coupled to be effecitve to use and maintain

Avoid breaking API changes

The internal implementation of any microservice should be readily changed without breaking an established (shared) API.

Once a microservice API is published to the system, only additional changes should be made to avoid breaking other services that depend on the microservice.

Where breaking changes are the only remaining option, extensive communication is essential across the organisation.

Page work in progress

Anatomy of a microserviceλ︎

  • Resource
  • service layer
  • domain model
  • Repositories
  • Persistent layer | Gateway


Abstract away the communication layer between micro-services

DDD Bounded contextλ︎

grouping your domain model in to self contained logical chunks

  • small islands of concepts with relationships between them
  • connection over rest or lightweight event bus
  • can be deployed quickly (hours not days/weeks)
  • understand the concequence of changes to a microservice


Microservices should not fail or cause others to fail

Comprehensive documentation should be maintained for each microservice, optionally generating and publishing the API documentation from the code of the service itself, e.g. swagger,

Testing should focus on maintaining a robust API, ensuring changes are additive to avoid breaking the overall system of microservices.

  • unit tests are self-contained, testing the handler functions that compose the overall API
  • integration tests ensure external services continue to provide expected results and shape of responses
  • end-to-end tests are very challenging when the system is first evolving, as design can change rapidly

unit tests should not delay the rate at which you deploy your microservices