The modern architecture of software systems must be both flexible and robust. Enter Domain-Driven Design (DDD) — a powerful approach that emphasizes collaboration between technical and domain experts to create a shared understanding of the problem space.
If you’re planning to develop an e-commerce application, you might have plenty of ideas but struggle to structure them properly. While searching for guidance, you come across a thick book on DDD. But let’s be honest — you probably won’t read it at the office or on public transport. That’s why this article is for you. It summarizes the key DDD concepts in a clear and concise way.
In DDD, concepts like Bounded Contexts, Subdomains, and the overall Domain are crucial for structuring complex software systems. But how do these elements interact? Why is it important to understand their relationships? And how do they fit into modern architectural paradigms like microservices?
In this article, we will explore the definitions and roles of subdomains and bounded contexts, analyze how they communicate, and delve into data-sharing strategies. By the end, you’ll have a practical understanding of how to apply DDD principles to your own projects.
Step 1: What Are Domains and Subdomains ?
The Domain represents the overall business problem space your application is addressing. Within this domain, we separate Subdomains into three categories:
Core Domain : What makes your business unique and gives you a competitive advantage. This is where the majority of your effort should go.
Supporting Subdomains : Necessary but not unique to your business. Important, but you can put less effort into them.
Generic Subdomains : Commodity services that can often be outsourced or handled by third-party providers.
Subdomains in our E-Commerce App would be as following :
By structuring your subdomains clearly, you ensure that your development effort is focused on the most critical parts of the business.
Step 2: What Is a Bounded Context ?
A Bounded Context is a self-contained model with clear boundaries. Within a bounded context:
- Terms, rules, and definitions apply consistently.
- It encapsulates a specific part of the business logic.
- Each bounded context is independent and does not leak concepts into others.
Eric Evans defines it as:
“A part of the software where particular terms, rules, and definitions apply consistently.”
Bounded Contexts in our E-Commerce App would be as following :
Each Bounded Context has its own database, business logic, and API to ensure loose coupling and scalability.
Step 3: How should Bounded Contexts communicate ?
Now that we have clear boundaries, we need to define how they interact. There are several key DDD strategic design patterns for managing these relationships:
Upstream & Downstream :
Upstream: A system that provides data to others.
Downstream: A system that depends on upstream services.
Example : The Payments Service (Upstream) processes transactions and updates Order Management (Downstream).
Customer/Supplier Pattern :
The Customer (Downstream) service relies on the Supplier (Upstream) and can negotiate changes.
Example: The Inventory System (Supplier) provides stock updates, and the E-commerce Website (Customer) depends on it.
Conformist Pattern :
The Customer must conform to the Supplier’s model, even if it’s not ideal.
Example: If using a 3rd-party Payment Provider, the E-commerce app must follow their API rules.
Separate Ways Pattern :
When two systems are too different, they remain separate.
Example: Product Reviews and Recommendation Systems may work independently.
So Bounded Contexts, in our E-Commerce App would communicate as following :
Step 4: Data Sharing & API Strategy
Now that we have a clear outline of our architecture, it’s important to define data sharing and communication strategies.
Anti-Corruption Layer (ACL) — Protecting Domain Models
When integrating with legacy or external systems, their data models may not match our domain. Instead of polluting our clean domain model, we introduce an Anti-Corruption Layer (ACL) as a translation layer.
Example: If our E-commerce app needs to integrate with a legacy Warehouse Management System, an ACL translates data before it enters our system.
Open Host Service (OHS) — Standardized APIs
When multiple external clients need access to a service, we should expose a standardized API.
Example: If multiple 3rd-party vendors need access to our Product Catalog, we should expose an API Gateway with well-defined contracts.
So using this concepts, our data sharing strategy would be implemented as following :
By structuring your software with DDD in mind, you ensure that your application remains scalable, maintainable, and aligned with the business needs.
Hope this article helped you understand DDD better. Have a nice day! 😊
Top comments (0)