Domain-Driven Design basics in LLD - System Design Exercise

Design: Domain-Driven Design Basics

Covers foundational concepts of Domain-Driven Design including modeling, bounded contexts, and key building blocks. Does not cover advanced tactical patterns or implementation details.

Functional Requirements

FR1: Understand how to model complex business domains using software

FR2: Identify core domain and subdomains

FR3: Define bounded contexts to separate different parts of the system

FR4: Use ubiquitous language shared by developers and domain experts

FR5: Design entities, value objects, aggregates, and repositories

FR6: Ensure clear separation between domain logic and infrastructure

Non-Functional Requirements

NFR1: Focus on clarity and maintainability over premature optimization

NFR2: Support evolving business requirements with flexible design

NFR3: Keep latency and performance reasonable for typical business applications

NFR4: Design for team collaboration between technical and non-technical members

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Entities with identity and lifecycle

Value objects representing immutable concepts

Aggregates as consistency boundaries

Repositories for data access abstraction

Bounded contexts to define clear model boundaries

Domain events to capture important changes

Design Patterns

Layered architecture separating domain, application, infrastructure

Context mapping to show relationships between bounded contexts

Ubiquitous language to unify communication

Event-driven design for decoupling

Anti-corruption layer to integrate with legacy systems

Reference Architecture

  +---------------------+       +---------------------+
  |  Bounded Context A   |       |  Bounded Context B   |
  |  +---------------+  |       |  +---------------+  |
  |  |   Entities    |  |       |  |   Entities    |  |
  |  | Value Objects |  |       |  | Value Objects |  |
  |  | Aggregates   |  |       |  | Aggregates   |  |
  |  +---------------+  |       |  +---------------+  |
  |  +---------------+  |       |  +---------------+  |
  |  | Repositories  |  |       |  | Repositories  |  |
  |  +---------------+  |       |  +---------------+  |
  +---------------------+       +---------------------+
            |                              |
            |          Context Map         |
            +------------------------------+
                       Integration

Components

Entity

Conceptual

Represents an object with a unique identity and lifecycle in the domain.

Value Object

Conceptual

Represents an immutable descriptive aspect of the domain without identity.

Aggregate

Conceptual

A cluster of domain objects treated as a single unit for data changes.

Repository

Interface/Pattern

Provides abstraction for retrieving and storing aggregates.

Bounded Context

Architectural Boundary

Defines a clear boundary within which a particular domain model applies.

Ubiquitous Language

Communication Practice

Shared language between developers and domain experts to avoid confusion.

Request Flow

1. 1. Domain experts and developers collaborate to define the ubiquitous language.

2. 2. Identify core domain and subdomains to focus modeling efforts.

3. 3. Define bounded contexts to separate different models and teams.

4. 4. Within each bounded context, design entities, value objects, and aggregates.

5. 5. Use repositories to abstract data access for aggregates.

6. 6. Implement domain logic inside aggregates to enforce business rules.

7. 7. Use context maps to manage integration between bounded contexts.

Database Schema

Entities have unique identifiers and attributes. Value objects are embedded within entities or aggregates without separate identity. Aggregates enforce consistency boundaries. Repositories map aggregates to database tables or collections. Bounded contexts may have separate schemas or databases to isolate models.

Scaling Discussion

Bottlenecks

Complex domain logic tightly coupled causing difficulty in changes

Overlapping bounded contexts leading to confusion and integration issues

Large aggregates causing performance bottlenecks during updates

Poor communication causing mismatch between domain model and business needs

Solutions

Refactor domain logic into smaller, focused aggregates and services

Clearly define and enforce bounded context boundaries with context maps

Design aggregates to be as small as possible to reduce locking and contention

Maintain continuous collaboration and update ubiquitous language regularly

Interview Tips

Time: Spend 10 minutes explaining core concepts and terminology, 15 minutes on how to identify bounded contexts and model aggregates, 10 minutes on integration and communication strategies, and 10 minutes on scaling and real-world challenges.

Importance of ubiquitous language for clear communication

How bounded contexts help manage complexity

Role of aggregates in maintaining consistency

Separation of domain logic from infrastructure

Strategies for evolving the domain model with business changes

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