Domain-Driven Design (DDD) basics in Microservices - System Design Exercise

Design: Domain-Driven Design (DDD) Basics for Microservices

Focus on designing the domain model and microservice boundaries using DDD principles. Out of scope: detailed UI design, infrastructure provisioning, and specific technology stacks.

Functional Requirements

FR1: Identify core business domains and subdomains

FR2: Define bounded contexts to isolate domain models

FR3: Design microservices aligned with bounded contexts

FR4: Enable clear communication between microservices

FR5: Support independent deployment and scalability of services

FR6: Maintain data consistency within each bounded context

Non-Functional Requirements

NFR1: System should handle up to 1000 concurrent users

NFR2: API response latency p99 under 300ms

NFR3: Availability target of 99.9% uptime

NFR4: Microservices must be loosely coupled and independently deployable

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Domain models representing business concepts

Bounded contexts defining service boundaries

Microservices implementing bounded contexts

APIs or messaging for inter-service communication

Databases scoped per bounded context

Design Patterns

Bounded Context pattern

Context Mapping

Aggregates and Entities

Domain Events

Anti-Corruption Layer

Reference Architecture

 +-------------------+       +-------------------+       +-------------------+
 |  User Management  | <---> |  Order Management  | <---> |  Inventory Service |
 |  Microservice     |       |  Microservice      |       |  Microservice      |
 +-------------------+       +-------------------+       +-------------------+
        |                            |                            |
        v                            v                            v
 +----------------+          +----------------+          +----------------+
 | User DB        |          | Order DB       |          | Inventory DB   |
 +----------------+          +----------------+          +----------------+

Each microservice owns its domain model and database.
Services communicate via APIs or events respecting bounded contexts.

Components

User Management Microservice

REST API, relational DB

Manages user domain including registration and profiles within its bounded context

Order Management Microservice

REST API, relational DB

Handles order processing domain, isolated from other domains

Inventory Microservice

Event-driven, NoSQL DB

Manages inventory domain and stock levels independently

API Gateway

HTTP reverse proxy

Routes client requests to appropriate microservices

Message Broker

Kafka or RabbitMQ

Supports asynchronous communication and domain events between services

Request Flow

1. Client sends request to API Gateway

2. API Gateway routes request to appropriate microservice based on bounded context

3. Microservice processes request using its domain model and database

4. If needed, microservice publishes domain events to Message Broker

5. Other microservices subscribe to relevant events and update their state accordingly

6. Microservice returns response to API Gateway, which forwards it to client

Database Schema

Entities are scoped per bounded context. For example, User entity exists only in User Management context with attributes like userId, name, email. Order entity exists in Order Management context with orderId, userId, orderItems. Inventory entity exists in Inventory context with productId, stockCount. Relationships between entities across contexts are handled via domain events or API calls, not direct database joins.

Scaling Discussion

Bottlenecks

Tight coupling between microservices causing deployment delays

High latency in synchronous inter-service calls

Database contention within a single bounded context

Difficulty maintaining data consistency across services

Solutions

Enforce strict bounded contexts and use asynchronous communication to reduce coupling

Implement event-driven architecture to decouple services and improve latency

Use database sharding or partitioning within bounded contexts to reduce contention

Apply eventual consistency with domain events and sagas for cross-service transactions

Interview Tips

Time: Spend 10 minutes understanding and clarifying requirements, 20 minutes designing bounded contexts and microservices, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain how bounded contexts help isolate domain models

Describe how microservices align with business domains

Discuss communication patterns between services (sync vs async)

Highlight data ownership and consistency strategies

Mention scalability and deployment independence benefits