A Typical Bounded Context in Domain-Driven Design
How should your bounded context look like? What classes can talk to which classes? What are the layers we can think of and which layer is responsible for what?
Join the DZone community and get the full member experience.Join For Free
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:
- Distributed Services Layer (REST)
- Application Layer
- Domain Layer
- Persistence Layer
- 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.
- 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.
- Heart of the application, All domain logic resides here.
- Responsible for all domain operations and commands.
- Not responsible for insertions, updations, and deletions.
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.
Hope you find this article informative. Feel free to share your thoughts.
Opinions expressed by DZone contributors are their own.