Photo by Hanna Morris on Unsplash

Serverless Domain Driven Design

Breaking down DDD concepts one at a time with real world examples into a tangible serverless equivalent architecture.

What we will be discussing as an example serverless architecture that was designed with DDD in mind.

What is Domain Driven Design?

Domain-driven design (DDD) is a software design approach focusing on modelling software to match a domain according to input from that domain’s experts.” —

What is Domain Driven Design in Serverless?

My own interpretation of DDD concepts with serverless microservices, and how this creates a reusable Domain Layer service pattern in the Serverless Architecture Layers

A Sub Domain equates to a single Domain Service. Below we have the Customer domain service which is made up of one or more AWS microservices.

An example of the Customers sub domain which is part of the overall e-commerce domain.

A sub domain is essentially a logically separated part of the overall domain based on its encapsulated business capabilities, which is a domain in its own right. Above we can see the sub domain for Customer which is a domain service.
The three domains types in order of importance to the business as differentiators to competitors

The Core domain should deliver about 20% of the total value of the entire system, be about 5% of the code base, and take about 80% of the effort.

“Supporting domains are candidates to be outsourced to less experienced development teams or 3rd parties”

Generic domains are those in which you should look at “buy before build” and purchasing from a 3rd party.

Example of an entity within an aggregate

“For example, an entity is an object defined not by its attributes, but its identity. As an example, most airlines assign a unique number to seats on every flight: this is the seat’s identity.” —

Example of a Value Object which does not have an identity as typically linked to an Entity which does
An aggregate which encapsulates one or more entities
The Bounded Context for the Customer Domain Service which includes both Customer and Loyalty Scheme microservices.

“A bounded context is simply the boundary within a domain where a particular domain model applies. We can group functionality according to whether various functions will share a single domain model.” —

Application services are typically part of the ‘Cross-cutting Layer’ when it comes to Serverless Architecture Layers.

Example of domain events being raised and consumed with regards to the domain service

From an Experience Layer perspective we can still raise events which are not necessarily ‘domain events’ as such, for example in the BFF of the Website a customer logging in could be a valid event. We could also utilise sentiment analysis to raise an event that ‘Customer X is unhappy’.

In some enterprise organisations a ubiquitous language needs defined globally when building domain services that can be internationalised and reused across regions

This could be a code repository for the sub domain which includes multiple independent AWS CDK apps.

This could be provisioned in its own ‘Infra’ AWS CDK app and deployed independently.

These microservices can be provisioned in their own AWS CDK apps and deployed independently.

The shared ESB (Enterprise Service Bus) would be an AWS CDK app which deploys an EventBridge bus into its own shared AWS account within an organisation.


Wrapping up 👋

About me



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Lee James Gilmore

Principal Serverless Engineer | Enterprise Cloud Architect | Serverless Advocate | Mentor | Blogger | AWS x 6 Certified 🚀