A Typical Bounded Context in Domain-Driven Design

As Martin Flower has said, Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams.

Having said that, many people design their APIs in their own way, and, probably we end up mixing the legacy thought process of design into the microservices world which may cost us in performance and adaptability, scaling.

How should your bounded context look like?

What classes can talk to which classes?

What are the layers we can think of while designing and which layer is responsible for what?

Let's deep dive now...

Bounded Content With Classified Layers

Below is a pictorial representation of bounded context with classified layers:

Clients would be interacting with our application over gateway with all authentication and authorization principles.

Ideally, we categorize all our classes into 5 different layers:

1. Distributed Services Layer (REST)
2. Application Layer
3. Domain Layer
4. Persistence Layer
5. Cross Cutting Layers

Distributed Services Layer

This layer is responsible for receiving requests from clients and delivering responses back. This is the only layer exposed to clients, other modules, and external systems. Not responsible for processing requests.

Application Layer

• Responsible for coordinating the use case.
• Responsible for authorization, the User's permissions are verified before invoking a use case.
• As a service orchestrator, facilitates the domain layer with the required information and resources.
• Can be responsible for processing queries but not for commands.
• Not responsible for performing any domain operations and commands.

Domain Layer

• Heart of the application, All domain logic resides here.
• Responsible for all domain operations and commands.
• Not responsible for insertions, updations, and deletions.

Persistence Layer

This layer is responsible for persisting the domain objects into the persistence store like a database and get back to them when required.

Cross Cutting Layers

This can be further classified into 3 more layers

• Cross Cutting — Communication Layer: Facilitates communication between other modules and external applications. Dispatching and receiving domain events to/from other modules.
• Cross Cutting — Operations Layer: Provides infrastructure services for logging and audit trail, log technical and business events both.
• Cross Cutting — Security Layer: Provides authentication and authorization services.

Unit of work and transaction scope would reside within application, domain, and persistence layers only. With this approach, we will be able to make our bounded context highly scalable and resilient to adapt to any changes in the ecosystem.

Wrap Up

Hope you find this article informative. Feel free to share your thoughts.

Cheers!