DDD - Concevoir des logiciels pour l'entreprise, pas pour la base de données (Ddd Concevoir Des Logiciels Pour Lentreprise Pas Pour La Base DE Donnees)

One domain, growing decisions

Keep one e-commerce ordering system in mind throughout this chapter. In year one, Order is a simple record carrying selected products and a total. CRUD is sufficient.

Year 1 → create, list, update orders
Year 2 → promotions and discounts
Year 3 → returns and partial payments
Year 4 → instalments, inventory reservation, shipment
Year 5 → fraud control and country-specific tax

Each need adds more than a field to Order; it adds a decision. A domain is not a software problem. It is the business problem being solved. Here it is the work of safely accepting, pricing, paying for, returning, and delivering an order.

Problème premier : pourquoi le code perd-il le langage du métier ?

Au début d'un produit, c'est souvent simple : dessiner le tableau, écrire le point final, ajouter l'enregistrement. Cette approche n’est pas fausse. Cependant, lorsque les règles de tarification, de rendement, de risque, de livraison et d’autorisation prolifèrent, la valeur du système n’est pas dans les tableaux ; Cela dépend de la bonne mise en œuvre de ces décisions.```text Veritabanı → Table → CRUD → Service katmanı → dağınık iş kuralları

İş dünyası → Ortak dil → Domain modeli → Kod → görünür kararlar

## Concepts à la première mention```text
📦 Domain
Sistemin çözmeye çalıştığı iş alanı: örneğin sipariş, kredi veya sigorta.

📦 Domain modeli
İşin kurallarını, kavramlarını ve geçişlerini kodda temsil eden model.

📦 Ubiquitous Language / Ortak Dil
İş uzmanı, ürün ve yazılım ekibinin aynı kavram için aynı adı kullanması.

📦 Core Domain
Ürünü gerçekten farklılaştıran ve en yüksek karar karmaşıklığını taşıyan iş alanı.
````PlaceOrder` est plus qu'un appel technique : il transmet l'intention de passer une commande. En cas de succès, `OrderPlaced` devient un fait commercial. Si les noms ne traduisent pas le langage de l'entreprise, l'équipe retraduit à chaque nouvelle fonctionnalité.

## Why does the same order break across layers?

When product says “Preferred Customer” while engineering sees only `Status = 1`, one concept has been split into two languages. Which meaning will the next promotion rule follow? Ubiquitous language reduces that ambiguity before implementation begins.

Likewise, `order.Status = Paid` is not a safe behaviour on its own:

```text
order.Status = Paid
  ↓
Was payment actually verified?       → unknown
Was inventory reserved?              → unknown
Could the order already be cancelled?→ unknown

order.ConfirmPayment(payment)
  ↓
verifies payment evidence
applies required business rules
rejects invalid transitions

The point is not to ban setters. It is to give a business rule one owner. Team size changes the economics too: in a short-lived application built by one or two people, CRUD simplicity wins; in a product evolved for years by more than ten people, shared language and explicit ownership pay back faster.

Pourquoi CRUD fonctionne-t-il très bien pendant de longues périodes ?

Si l'équipe est petite, le produit est unique et les règles peu nombreuses, le flux Controller → Service → Repository → Database est rapide et simple. Pour les écrans d’inscription simples, les panneaux d’administration et les prototypes éphémères, cette simplicité est un réel avantage. DDD n'est pas une idéologie contre CRUD.

La rupture ne se produit pas lorsque plusieurs enregistrements sont ajoutés à la même table ; Cela commence lorsque le même modèle doit représenter différentes intentions commerciales. Un Order est utilisé à la fois pour la promotion, les taxes, les remises, les retours, la réservation de stock, la livraison et le contrôle des risques.```text Database-first OrderRow → status = 2 → UpdateOrderStatus()

Business-first Order → ConfirmPayment() → ReserveInventory() → StartFulfilment()

## Langage commun : supprimer la taxe sur la traduction

Si l'expert métier dit « client privilégié » et que le code dit `UserStatus = 1`, le système a deux réalités différentes. Cette différence provoque une incompréhension du nouveau membre de l'équipe, la règle est répétée dans différents services et les réunions se transforment en séances d'explications constantes.```text
❌ InsertNewSchoolYear()
✓ OpenNewSchoolYear()

❌ UserStatus = 1
✓ customer.MarkAsPreferred()

❌ OrderRow
✓ LoanApplication / Order / Subscription
```Le langage courant ne consiste pas à remplacer chaque nom technique par un terme commercial. Le modèle doit être suffisamment précis pour expliquer les décisions dans ce contexte. De même que la carte ne montre pas le monde entier, mais la réalité nécessaire au voyage ; Le modèle de domaine représente la décision commerciale pertinente, et non toutes les données.

## Modèle anémique : faire des données un objet et du comportement une procédure

Le modèle de domaine exsangue est une structure dans laquelle les classes de services gèrent des entités remplies de setters publics. `OrderService`, `PricingService`, `DiscountService` et `ShipmentService` commencent à appliquer les mêmes règles à différents endroits au fil du temps. L'objet ne transporte que des données ; le comportement reste à l’écart.```text
❌ order.Status = Paid
❌ order.Total = -10

✓ order.ConfirmPayment(payment)
✓ order.ApplyDiscount(discount)
```Le but du modèle riche n’est pas de tout regrouper dans une seule entité. Mais cela signifie respecter les règles du système, qui ne doivent jamais être enfreintes, ainsi que le comportement. Par exemple, une commande ne peut être expédiée tant que le paiement n'est pas vérifié. Il ne devrait y avoir qu'un seul propriétaire de cette règle.

## Le coût et le contexte correct du DDD

JJD ; Cela nécessite une analyse, des séances de langage commun, une dénomination plus soignée et une discipline d'équipe. Ce coût n’est pas rentable avec une simple saisie de données. La décision n’a pas été prise avec un enthousiasme technique ; Il doit être pris en compte avec la complexité du domaine et le taux de changement.

| Signalisation | CRUD est plus pratique | L'investissement DDD a du sens |
| --- | --- | --- |
| Règle métier | Faible et stable | Stratifié, critique, en constante évolution |
| Durée de vie du produit | Prototype court | Produit longue durée |
| Coût de l'erreur | Faible | Élevé financièrement ou opérationnellement |
| Discussion d'équipe | univoque | Le même concept a des significations différentes |

À mesure que le nombre de règles augmente, le coût de fonctionnement de la solution devient souvent non linéaire. Lorsqu'une règle `k` est répétée dans un service différent, le coût de modification est d'au moins O(k) ; Les cas de test se développent plus rapidement si les règles s'influencent mutuellement. DDD ne rend pas ce coût nul par magie ; Cela rend visibles la propriété et les limites.

## Première étape : observer le langage, ne pas réécrire le code

1. Choisissez le flux de travail dans lequel les décisions les plus coûteuses se produisent.
2. Enregistrez les verbes et les noms utilisés par le professionnel.
3. Clarifiez les termes contradictoires dans un contexte unique.
4. Modélisez le nouveau comportement comme une intention commerciale plutôt que comme une mise à jour d'un champ de données.
5. Incluez uniquement les comportements qui empêchent l'état non valide à cette limite.

Dans ce processus, la base de données, le framework et l'API sont les adaptateurs ; Ce n'est pas le propriétaire de la décision de domaine.

## Correspondances qui créent une fausse confiance```text
❌ DDD = katmanlı mimari
✓ DDD = karmaşık iş alanını modelleme disiplini

❌ DDD = çok fazla interface
✓ DDD = kararların ve kuralların doğru sahibini bulmak

❌ Her projede DDD gerekir
✓ Yatırım, karmaşık ve değişen domain'de geri döner

❌ Aggregate = entity grubu
✓ Aggregate = tutarlılığın korunacağı transaction sınırı

❌ Repository = her tablo için vardır
✓ Repository, domain'de anlamlı aggregate root'lar içindir

Liste de contrôle de décision

• Quelle règle est violée lorsque l'erreur commerciale la plus coûteuse se produit ?
• L'expert métier et le code font-ils référence au même concept avec le même mot ? - status = 2 est-il un changement de statut ou un comportement commercial significatif ?
• Y a-t-il un seul propriétaire de la règle ? Ou est-ce répété dans différents services ?
• Ce domaine est-il suffisamment complexe pour que le coût de l'analyse soit rentable à long terme ?

S’il n’y a pas de réponse claire à ces questions, ne choisissez pas d’abord l’entité ou le cadre. Clarifiez d’abord le problème, la langue et les limites.

Ce qu'il faut retenir de cet article

1. DDD n’est pas contre la base de données ; Il s’agit d’une approche de conception qui reconnaît que les règles métier ont plus de valeur que les données.
2. Langage commun, pas de notes de réunion ; C'est un contrat de code, d'API et de décisions.
3. Le modèle sans effusion de sang amplifie le risque d'états invalides en distribuant le comportement à la couche de service.
4. DDD n'est pas présent dans tous les projets ; Où la complexité et le changement génèrent des coûts et des retours sur investissement.

La valeur du logiciel ne réside pas dans le stockage des données ; La capacité de maintenir les bonnes décisions du travail pendant longtemps.

Dans la section suivante, nous ramènerons cet état d'esprit au niveau du code : limites de l'objet de valeur, de l'entité et de l'agrégat.

Before moving to tactical patterns

Where do these business decisions live in code? Tactical DDD patterns such as Value Objects, Entities, and Aggregates answer that question. They are not the starting point, however; they are tools for protecting the language, rules, and boundaries made clear here.