Le Domain-Driven Design, ou DDD, est une approche de conception logicielle qui place le métier au centre du développement. L’idée est de collaborer étroitement avec les experts métier pour bien comprendre les règles fonctionnelles, et les modéliser dans le code à travers un langage commun, qu’on appelle langage omniprésent.

Concrètement, on structure l’application autour de concepts comme les entités, les objets-valeurs, les agrégats, les services de domaine et les dépôts (repositories), dans le but d’isoler et de clarifier la logique métier.

C’est particulièrement utile dans les domaines complexes, parce que ça permet de faire évoluer le cœur métier sans être trop couplé à la base de données, à l’interface ou à un framework technique.

🔑 Core Ideas (Super Simple) #

Domain

• The area of knowledge your app is about (e.g., banking, e-commerce, healthcare).

Entity

• An object with an identity (e.g., User, Order) that changes over time.

Value Object

• An object with no identity, just values (e.g., Money, Address).

Aggregate

• A group of related objects treated as one unit, with one root (Order with its OrderItems).

Repository

• A way to get and store aggregates (OrderRepository to load/save orders).

Service

• Logic that doesn’t belong to a single object (e.g., PaymentService).

Use Case / Application Service

• Coordinates user actions (e.g., PlaceOrder use case calls the right domain logic).

Ubiquitous Language

• Use the same language everywhere (code, docs, meetings) to reduce confusion.