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

Practice

1. What is the main purpose of Domain-Driven Design (DDD) in microservices?

easy

A. To align software design closely with business needs

B. To improve database query performance

C. To create user interfaces faster

D. To reduce network latency between services

Solution

1. Step 1: Understand the goal of DDD

   DDD focuses on modeling software based on the real business domain and its rules.

2. Step 2: Compare options with DDD goals

   Only aligning software with business needs matches DDD's main purpose.

3. Final Answer:

   To align software design closely with business needs -> Option A

4. Quick Check:

   DDD = Align software with business [OK]

Hint: DDD = software matches business needs [OK]

Common Mistakes:

• Confusing DDD with performance optimization
• Thinking DDD is about UI or network improvements
• Assuming DDD is only about coding style

2. Which of the following is a correct way to describe a 'Bounded Context' in DDD?

easy

A. A network protocol used for service communication

B. A database table shared by all microservices

C. A UI component that handles user input

D. A clear boundary within which a domain model applies

Solution

1. Step 1: Define Bounded Context

   It is a boundary that defines where a particular domain model is valid and consistent.

2. Step 2: Match options to definition

   Only 'a clear boundary within which a domain model applies' correctly describes a Bounded Context.

3. Final Answer:

   A clear boundary within which a domain model applies -> Option D

4. Quick Check:

   Bounded Context = domain model boundary [OK]

Hint: Bounded Context = domain model boundary [OK]

Common Mistakes:

• Thinking it is a shared database table
• Confusing it with UI or network concepts
• Assuming it is a technical infrastructure term

3. Given the following description, which DDD building block is being described?
A unique object with an identity that persists over time and changes state.

medium

A. Value Object

B. Entity

C. Aggregate

D. Repository

Solution

1. Step 1: Understand the description

   The object has a unique identity and can change state over time.

2. Step 2: Match description to DDD concepts

   Entities have unique identities and mutable state; value objects do not have identity.

3. Final Answer:

   Entity -> Option B

4. Quick Check:

   Unique identity + state = Entity [OK]

Hint: Entity = unique identity and state [OK]

Common Mistakes:

• Confusing Entity with Value Object
• Thinking Aggregate is a single object only
• Mixing Repository with domain objects

4. You have a microservice with a large domain model mixing unrelated concepts. What DDD principle helps fix this?

medium

A. Define clear Bounded Contexts to separate domains

B. Avoid using entities and only use value objects

C. Merge all services into one monolith

D. Use a single aggregate for all entities

Solution

1. Step 1: Identify the problem

   The domain model is large and mixes unrelated concepts, causing complexity.

2. Step 2: Apply DDD principle

   Bounded Contexts separate different domain areas to keep models clear and manageable.

3. Final Answer:

   Define clear Bounded Contexts to separate domains -> Option A

4. Quick Check:

   Separate domains with Bounded Contexts [OK]

Hint: Separate domains using Bounded Contexts [OK]

Common Mistakes:

• Trying to use one aggregate for everything
• Merging services instead of separating
• Removing entities incorrectly

5. In a microservices system using DDD, which approach best ensures data consistency within a complex domain involving multiple aggregates?

hard

A. Use transactions spanning multiple microservices

B. Store all data in a single shared database

C. Design aggregates as consistency boundaries and use eventual consistency between them

D. Avoid aggregates and use only value objects for all data

Solution

1. Step 1: Understand consistency in DDD aggregates

   Aggregates define consistency boundaries; transactions should not span multiple aggregates or services.

2. Step 2: Choose best practice for microservices

   Use eventual consistency and asynchronous communication between aggregates to maintain scalability and reliability.

3. Final Answer:

   Design aggregates as consistency boundaries and use eventual consistency between them -> Option C

4. Quick Check:

   Aggregates = consistency boundaries + eventual consistency [OK]

Hint: Aggregates limit transactions; use eventual consistency [OK]

Common Mistakes:

• Trying distributed transactions across services
• Using a shared database breaking microservice boundaries
• Ignoring aggregates and consistency rules