Domain Driven Design (DDD)

Domain-Driven Design (DDD) is a software design approach that focuses on modeling software based on the core business domain and its rules, rather than just technical concerns. It helps developers build software that's aligned closely with how the business actually works.

"Let the business drive the design."
Model your software structure and behavior around the business domain, using a shared language between developers and domain experts.

Key Concepts 

1. Domain

• The subject area your app is built for (e.g., banking, healthcare, logistics).

2. Entities

• Objects with a distinct identity that runs through time and different states.
• Example: Customer, Order

3. Value Objects

• Objects that have no identity and are defined only by their values.
• Example: Money, DateRange, Address

4. Aggregates

• A cluster of domain objects treated as a single unit.
• One entity is the aggregate root.
• Example: Order (root) → contains OrderLines (value objects)

5. Repositories

• Provide access to aggregates from a data store.
• Encapsulate the logic to fetch and store entities.

6. Services

• Used when behavior doesn’t naturally fit into an entity or value object.
• Example: CurrencyConversionService

7. Domain Events

• Captures things that happen within the domain.
• Example: OrderPlaced, PaymentReceived

8. Ubiquitous Language

• A common language used by both developers and domain experts.
• Used in code, documentation, conversations, and tests.

It’s a shared vocabulary used by developers, domain experts, QA, PMs—basically, everyone working on a project—to describe the domain and its behavior.

The goal is to eliminate miscommunication between tech and business by making sure everyone speaks the same language—literally.

Example

Let’s say you’re working on a loan approval system. Business experts might talk like this:

• “A loan application can be either approved or rejected.”
• “Every applicant needs a credit score and income verification.”
• “We send a risk assessment before final approval.”

With DDD and Ubiquitous Language:

• Your class is called LoanApplication, not FormData.
• You have a method Approve() not SetStatus("A").
• There’s a service called RiskAssessmentService.
• You model CreditScore as a value object. 

Good Ubiquitous Language:

• Comes directly from conversations with domain experts
• Is used in code (classes, method names, events, variables) 
• Is used in documentation, tests, and discussions 
• Avoids technical jargon unless it’s part of the domain