Domain-Driven Design basics in LLD - Scalability & System Analysis

Scalability Analysis - Domain-Driven Design basics

Growth Table: Domain-Driven Design Basics

Users / Scale	100 Users	10,000 Users	1,000,000 Users	100,000,000 Users
Domain Model Complexity	Simple, few bounded contexts	Multiple bounded contexts emerge	Many bounded contexts, complex aggregates	Highly modular domains, strict context boundaries
Team Structure	Small team, single team owns domain	Multiple teams per bounded context	Large teams, clear ownership per context	Many teams, microservices aligned with contexts
Communication	Direct, informal	Defined interfaces between contexts	Asynchronous messaging, event-driven	Automated contracts, API gateways
Data Management	Single database, simple schema	Separate databases per bounded context	Database per microservice, eventual consistency	Polyglot persistence, CQRS, event sourcing
Scaling Focus	Code clarity, domain understanding	Modularization, decoupling	Service isolation, independent deploys	Global distribution, resilience, automation

First Bottleneck

At small scale, the main bottleneck is unclear domain boundaries causing confusion and slow development.

As users grow, the bottleneck shifts to communication overhead between teams and tightly coupled code.

At large scale, data consistency and integration between bounded contexts become the bottleneck.

Scaling Solutions

• Define clear bounded contexts: Separate domain areas to reduce complexity and team conflicts.
• Use context maps: Explicitly document relationships and integration patterns between contexts.
• Apply microservices: Align services with bounded contexts for independent scaling and deployment.
• Implement asynchronous communication: Use events and messaging to decouple contexts and improve scalability.
• Adopt eventual consistency: Accept temporary data differences to improve performance and availability.
• Use domain events and event sourcing: Capture changes as events for auditability and replay.
• Automate testing and deployment: Ensure safe changes in complex domain models.

Back-of-Envelope Cost Analysis

Assuming 10,000 active users generating 1 request per second:

• Requests per second: ~10,000 QPS
• Database queries: 20,000 QPS (including reads and writes)
• Storage: Depends on domain events and aggregates; estimate 100GB/month for event store
• Network bandwidth: ~100 Mbps assuming 10KB per request/response
• Compute: Multiple app servers to handle load, plus messaging infrastructure

Scaling beyond 100,000 users requires sharding databases, adding read replicas, and partitioning event streams.

Interview Tip

When discussing Domain-Driven Design scalability, start by explaining bounded contexts and their importance.

Describe how clear domain boundaries reduce complexity and improve team autonomy.

Explain how asynchronous communication and eventual consistency help scale integrations.

Finally, mention how microservices and event-driven patterns support independent scaling and deployment.

Self Check

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Introduce read replicas and caching to reduce load on the primary database before considering sharding or redesign.

Key Result

Domain-Driven Design scales by defining clear bounded contexts, decoupling teams and data, and adopting asynchronous communication and microservices to handle complexity and traffic growth.

Practice

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

easy

A. To model software closely around real business concepts

B. To optimize database queries for performance

C. To create user interfaces quickly

D. To write code without any documentation

Solution

1. Step 1: Understand the goal of DDD

   DDD focuses on aligning software design with the core business domain and its logic.

2. Step 2: Compare options with DDD purpose

   Only To model software closely around real business concepts describes modeling software around business concepts, which is the essence of DDD.

3. Final Answer:

   To model software closely around real business concepts -> Option A

4. Quick Check:

   DDD = model software on business concepts [OK]

Hint: DDD = software models business ideas clearly [OK]

Common Mistakes:

• Confusing DDD with UI or database optimization
• Thinking DDD is about coding speed only
• Ignoring the business domain focus

2. Which of the following is the correct definition of an Entity in DDD?

easy

A. An object defined only by its attributes and no identity

B. A database table storing raw data

C. An object with a unique identity that persists over time

D. A service that performs calculations without state

Solution

1. Step 1: Recall Entity characteristics in DDD

   Entities have a unique identity that remains constant even if attributes change.

2. Step 2: Match definitions with Entity concept

   An object with a unique identity that persists over time correctly states that Entities have unique identity and persistence over time.

3. Final Answer:

   An object with a unique identity that persists over time -> Option C

4. Quick Check:

   Entity = unique identity object [OK]

Hint: Entity always has unique identity, not just attributes [OK]

Common Mistakes:

• Confusing Entities with Value Objects
• Thinking Entities have no identity
• Mixing Entities with Services

3. Consider this simplified DDD code snippet in Python:

class Order:
    def __init__(self, order_id, items):
        self.order_id = order_id
        self.items = items

order1 = Order(1, ['apple', 'banana'])
order2 = Order(1, ['apple', 'banana'])

print(order1 == order2)

What will be the output?

medium

A. True

B. False

C. SyntaxError

D. None

Solution

1. Step 1: Understand default equality in Python classes

   By default, Python compares object references, so two different instances with same data are not equal.

2. Step 2: Analyze the code output

   order1 and order2 are different objects with same data, so order1 == order2 returns False.

3. Final Answer:

   False -> Option B

4. Quick Check:

   Default object equality compares references = False [OK]

Hint: Default == compares object identity, not data [OK]

Common Mistakes:

• Assuming == compares data automatically
• Expecting True because attributes match
• Confusing syntax error with logic error

4. In a DDD model, a Value Object should be immutable. Which of the following code snippets violates this principle?

medium

A. class Money:
def __init__(self, amount, currency):
self.amount = amount
self.currency = currency

B. class Money:
def __init__(self, amount, currency):
self._amount = amount
self._currency = currency

C. class Money:
def __init__(self, amount, currency):
self._amount = amount
self._currency = currency
@property
def amount(self):
return self._amount

D. class Money:
def __init__(self, amount, currency):
self.amount = amount
self.currency = currency
def change_amount(self, new_amount):
self.amount = new_amount

Solution

1. Step 1: Recall immutability in Value Objects

   Value Objects should not allow changes after creation to keep consistency.

2. Step 2: Identify mutable code

   class Money: def __init__(self, amount, currency): self.amount = amount self.currency = currency def change_amount(self, new_amount): self.amount = new_amount has a method that changes the amount, violating immutability.

3. Final Answer:

   Code with method changing amount violates immutability -> Option D

4. Quick Check:

   Value Object must be immutable = no setters [OK]

Hint: Value Objects cannot change state after creation [OK]

Common Mistakes:

• Allowing setters or methods that modify attributes
• Confusing immutability with read-only properties only
• Ignoring methods that change internal state

5. You are designing a DDD model for an online store. Which of the following best represents an Aggregate?

hard

A. An Order object that contains multiple OrderItems and enforces business rules

B. A single Product object with price and description

C. A database table storing customer addresses

D. A utility service that calculates discounts

Solution

1. Step 1: Understand Aggregate in DDD

   An Aggregate is a cluster of related objects treated as a single unit with a root entity controlling consistency.

2. Step 2: Match options with Aggregate concept

   An Order object that contains multiple OrderItems and enforces business rules describes an Order with multiple OrderItems and business rules, fitting Aggregate definition.

3. Final Answer:

   An Order object containing multiple OrderItems and enforcing business rules -> Option A

4. Quick Check:

   Aggregate = root entity + related objects [OK]

Hint: Aggregate = root entity plus related objects as one unit [OK]

Common Mistakes:

• Confusing single entities with aggregates
• Thinking utility services are aggregates
• Mixing database tables with domain aggregates