Domain-driven design (DDD) is a way of building software where you let the business problem shape the code, instead of letting frameworks or databases dictate the design.
## Core idea
DDD focuses on the *domain*—the real-world problem space like trading, lending, logistics, or healthcare—and tries to mirror that in the software model.
Developers work closely with domain experts so the concepts, terms, and rules used in conversation match what appears in the code.
## Key concepts
- Domain: The problem area your software addresses, with its entities, rules, and workflows.
- Core domain: The most important, differentiating part of the business where correctness and clarity matter most.
- Ubiquitous language: A shared, precise vocabulary used in both conversations and code; class and method names use the same terms the business uses.
- Domain model: The conceptual and code representation of the domain, capturing entities, value objects, rules, and invariants.
## Building blocks in code
- Entities: Objects identified by a stable identity over time (e.g., Customer, Account, Order), whose state can change while they remain the same “thing.”
- Value objects: Immutable objects defined only by their values (e.g., Money, Address, DateRange), easy to replace with another instance that has the same data.
- Aggregates: Groups of entities and value objects treated as a consistency boundary, with a single root entity that enforces business rules.
- Domain services: Operations that belong to the domain but don’t sit naturally on a single entity or value object.
- Repositories: Abstractions for loading and saving aggregates, so domain logic doesn’t depend on database details.
## Strategic structure
- Bounded contexts: Clear boundaries inside a large system where a specific model and language apply; the same term can mean different things in different contexts.
- Context mapping: Describing how bounded contexts relate and communicate, and where you translate between different models.
## When DDD is useful
DDD is most valuable when the domain is complex and evolving, misalignment between business and code is expensive, and the system will live for years.
For a simple CRUD admin tool, it’s usually overkill; for something like a trading or risk engine, contract lifecycle platform, or loan origination system, it can pay off heavily.
Citations:
[1] Domain-Driven Design (DDD)
[2] Domain-Driven Design (DDD)
[3] Domain-driven design - Wikipedia
[4] What is Domain-Driven Design? Benefits, Challenges & ...
[5] Domain-Driven Design (DDD): A Summary
[6] An Introduction to Domain-Driven Design (DDD) https://khalilstemmler.com/articles/domain-driven-design-intro/
[7] Domain Driven Design in 10 minutes - part one
[8] Domain Driven Design - Martin Fowler
[9] Best Practice - An Introduction To Domain-Driven Design
[10] Understanding Domain-Driven Design (Part 1) https://www.reddit.com/r/programming/comments/196jwlb/understanding_domaindriven_design_part_1/
Perplexity
H/t mleku

Redis
Domain-Driven Design (DDD)
Domain-Driven Design: A strategy for aligning software development with complex business needs through a shared ubiquitous language.

GeeksforGeeks
Domain-Driven Design (DDD) - GeeksforGeeks
Your All-in-One Learning Portal: GeeksforGeeks is a comprehensive educational platform that empowers learners across domains-spanning computer scie...
Domain-driven design - Wikipedia

What is Domain-Driven Design? Benefits, Challenges & Implementation
Domain-Driven Design is a software development approach that models software development based on the input from the domain it is meant to serve.
Domain-Driven Design (DDD): A Summary – Software Engineering: A Modern Approach

Thoughtworks
Domain Driven Design in 10 minutes - Part one
In part one of this two-part series, Will Loughney, Software Developer, Thoughtworks will introduce the concept of Domain Driven Design and how it ...
Domain Driven Design

Best Practice - An Introduction To Domain-Driven Design

