Domain-Driven Design (DDD) basics in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Bounded Context in DDD

In Domain-Driven Design, what best describes a Bounded Context?

A A user interface component that handles domain logic

B A physical server where microservices are deployed

C A database schema shared by all microservices

D A clearly defined boundary within which a particular domain model applies and is consistent

💡 Hint

Think about where a domain model's rules and language stay consistent.

A Bounded Context defines a boundary where a specific domain model is valid and consistent. It helps teams avoid confusion by separating different models.

❓ Architecture

intermediate

Identifying Aggregates in a Domain Model

Which of the following best represents an Aggregate in Domain-Driven Design?

A A microservice that handles user authentication

B A cluster of domain objects treated as a single unit for data changes, with one root entity controlling access

C A database table storing all user data

D A UI widget that displays aggregated data

💡 Hint

Think about grouping related domain objects with a single entry point.

An Aggregate is a group of related domain objects that are treated as a single unit for data changes. It has a root entity that controls access to the group.

❓ scaling

advanced

Scaling Microservices with Bounded Contexts

When scaling a system using Domain-Driven Design, how does defining Bounded Contexts help with microservice scalability?

A It forces all microservices to share the same database for consistency

B It requires all microservices to be deployed on the same server to reduce latency

C It allows independent teams to develop and deploy microservices without conflicts by isolating domain models

D It merges all domain models into one to simplify scaling

💡 Hint

Consider how boundaries affect team autonomy and deployment.

Bounded Contexts isolate domain models, enabling teams to work independently and deploy microservices separately, which improves scalability and reduces conflicts.

❓ tradeoff

advanced

Tradeoffs of Using Domain Events in DDD Microservices

What is a common tradeoff when using Domain Events to communicate between microservices in a DDD architecture?

A Improved decoupling but increased complexity in ensuring eventual consistency

B Reduced network traffic but higher database load

C Faster synchronous communication but less fault tolerance

D Simpler code but tightly coupled services

💡 Hint

Think about asynchronous communication and data consistency.

Domain Events help decouple microservices by enabling asynchronous communication, but they introduce complexity in managing eventual consistency across services.

❓ estimation

expert

Estimating Capacity for a Microservice Based on Domain Load

A microservice handles orders in an e-commerce system. On average, it processes 500 orders per minute, each requiring 3 database writes and 2 external API calls. If each database write takes 10ms and each API call takes 50ms, what is the minimum number of concurrent processing threads needed to handle the load without delay?

A 100 threads

B 200 threads

C 50 threads

D 500 threads

💡 Hint

Calculate total processing time per order and orders per minute, then find threads needed.

Each order requires (3 * 10ms) + (2 * 50ms) = 30ms + 100ms = 130ms processing time. 500 orders per minute = ~8.33 orders per second. Total processing time per second = 8.33 * 130ms = 1083ms. To handle this load without delay, threads needed = total processing time per second / 1000ms ≈ 1.083, but since processing is concurrent, multiply by orders per second: 8.33 * 130ms / 1000ms = ~1.08 threads per order, so for 8.33 orders, about 11 threads are needed to handle concurrency and latency.