Comment DDD fonctionne-t-il sur les grands systèmes ? (Comment Ddd Fonctionne T Il Sur Les Grands Systemes)

Laissons d'abord tomber la mauvaise question

Le premier jour, il n'y avait qu'un seul modèle Book. Ensuite, l'équipe commerciale a demandé un prix, l'équipe d'expédition a demandé un créneau de livraison et a ajouté des informations sur la campagne marketing. Six mois plus tard, la même salle de classe s’est transformée en un objet que personne n’a pleinement compris. Le problème n’est pas que le livre s’agrandisse ; différentes intentions commerciales ont été chargées dans un seul modèle.

Diviser un grand système en microservices n’implémente pas DDD. Premièrement, il est nécessaire de comprendre quelles parties de l’entreprise ont des langages, des décisions et des rythmes de changement différents. Sinon, vous produirez un monolithe distribué plus cher au lieu d'un monolithe.```text Tek model → herkesin ihtiyacını taşımaya çalışır → model gerilimi

Satış bağlamı → fiyat ve müşteri kredisi Kargo bağlamı → teslimat adresi ve paket Katalog bağlamı → başlık, ISBN ve metaveri

## Concepts à la première mention```text
📦 Bounded Context
Bir modelin, dilin ve kuralların kendi içinde tutarlı kaldığı açık sınır.

📦 Context Mapping
İki bağlamın veri, güç ve sözleşme ilişkisini bilinçli olarak tanımlama pratiği.

📦 Upstream / Downstream
Veriyi veya sözleşmeyi sağlayan taraf upstream; ona bağımlı tüketen taraf downstream'dir.

📦 Anti-Corruption Layer (ACL)
Dışarıdaki modelin kavramlarını kendi domain'inize sızmadan çeviren katman.
```L'explication simple de la loi de Conway est la suivante : tout comme l'organisation communique, le logiciel reflète cette structure au fil du temps. Bounded Context n'est pas un microservice ; tout d'abord, il peut vivre comme un langage, une propriété et une limite de code distincts au sein d'un monolithe modulaire.

## Grande image```text
                         Şirket
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
    Katalog              Satış                Kargo
       │                    │                    │
     Book               Customer             Recipient
       │                    │                    │
       └──────── OrderConfirmed event ────────┘
                            │
                         Outbox
                            │
                          Broker
                            │
                     Delivery projection
```Ce diagramme n'inclut pas le nombre de services physiques ; Cela montre à quelle frontière vivent le langage, la propriété et le changement.

## Pourquoi la recherche du seul vrai modèle est-elle interrompue ?

Dans un catalogue de livres, il s'agit du titre, de l'auteur et de l'ISBN ; en prêt, c'est la copie physique en rayon ; Le SKU et le prix sont en vente. Les combiner tous en une seule classe `Book` ne consiste pas à les réutiliser, mais plutôt à lier différentes intentions ensemble. La même tension est observée pour `Customer` : l'équipe commerciale demande des informations de crédit et de facturation, tandis que la cargaison ne demande que l'adresse et les préférences de livraison.```text
❌ Unified Customer
creditLimit + invoiceAddress + deliveryWindow + marketingConsent + ...

✓ Sales.Customer
creditLimit + billingProfile

✓ Shipping.Recipient
deliveryAddress + deliveryWindow
```Le problème n'est pas le nombre d'objets. Il s'agit de la modification d'un même modèle par différentes équipes pour différentes raisons. Ce coût de changement devient d'au moins O(k) à mesure que le nombre de contextes affectés `k` augmente ; Lorsque les dépendances prolifèrent, les coûts de tests et de coordination augmentent plus rapidement.

## Contexte délimité : tracez d'abord la limite avec la langue du poste

Ne surveillez pas les couches techniques ou les tables de base de données pour détecter la limite. Surveillez ces signaux :

1. Le même mot signifie-t-il des choses différentes lors de la réunion ?
2. Les cas particuliers tels que `if (shipping)`, `if (sales)` se multiplient-ils dans un modèle ?
3. Les équipes s’attendent-elles constamment les unes aux autres pour le même changement ?
4. La propriété d'un domaine, la mesure du succès et le rythme du changement ne sont-ils pas clairs ?

La loi de Conway constitue ici une mise en garde : les limites de communication du système reflètent souvent la manière dont l'organisation communique. Si l'on s'attend à ce qu'une équipe prenne des décisions indépendantes, le modèle et la limite de déploiement de cette équipe doivent être aussi indépendants que possible. Il ne s'agit pas d'un objectif technique, mais d'une décision de propriété.

## Commencez dans Monolith ; voir le microservice comme résultat

Le moyen le moins risqué de vérifier le contexte limité consiste à utiliser un monolithe modulaire. Le contexte possède ses propres composants d'application/domaine/infrastructure, son accès aux données et son contrat explicite ; mais il ne supporte pas encore le coût opérationnel des appels distribués.```text
Catalog module ── published contract ──► Sales module
Sales module   ── domain event ─────────► Shipping module

Her module: kendi dilini, use case'lerini ve sahipliğini korur
```La migration vers des microservices n'a de sens que lorsqu'il existe un besoin avéré, comme une mise à l'échelle indépendante, un déploiement indépendant, des limites de sécurité différentes ou une véritable autonomie d'équipe. Contexte limité = L'égalité des microservices est la raison la plus courante d'un déploiement précoce.

## Context Mapping : l'intégration ne doit pas être une coïncidence

La relation entre les contextes est déterminée par l'équilibre des pouvoirs et la contamination du modèle, et non par les points de terminaison de l'API.

| Statut | Stratégie appropriée | Pourquoi |
| --- | --- | --- |
| Modèle hérité chaotique | LCA | Empêche le langage externe de s'infiltrer dans le domaine |
| Un grand nombre de consommateurs | Service hôte ouvert + langue publiée | Partage le contrat versionné, pas le modèle interne |
| Vous n'avez aucune influence en amont, le modèle est propre | Conformiste | N'installe pas de couches de traduction inutiles |
| Pièce commune petite et rarement modifiée | Noyau partagé, dernier recours | Accepte les frais de coordination |

Dans l'exemple ACL, le contexte cargo convertit le champ `CUST_TIER=7` de l'ERP existant en son propre concept `DeliveryEligibility`. Le terme ERP ne relève pas du domaine du fret. Cette couche représente le coût du code supplémentaire ; En échange, lorsque le système externe change, l’effet reste à un seul point de traduction.

## Événement, Boîte d'envoi et cohérence éventuelle

Un contexte ne doit pas lire la base de données d'un autre contexte. Lorsque le service commercial confirme une commande, il peut émettre l'événement `OrderConfirmed` ; cargo génère sa propre vue de livraison à partir de cela. L'événement n'interdit pas complètement les appels synchrones ; mais réduit la dépendance temporelle dans un flux de travail indépendant.```text
Sales transaction
  → Order'ı kaydet
  → Outbox'a OrderConfirmed yaz
  → Commit

Relay → Broker → Shipping consumer → Delivery projection
```La boîte d'envoi est requise car le courtier et la base de données ne partagent pas la même transaction ACID. S'il y a un enregistrement de commande, il y a aussi un événement à diffuser ; Le relais peut réessayer. Le consommateur doit être idempotent car il peut recevoir des événements en double. La cohérence finale n'est pas une erreur, mais une fenêtre de temps visible que le produit doit accepter.

## Le prix de ce design

Les limites du contexte nécessitent plus d'accords, d'observabilité, de gestion des versions et de discipline d'équipe. Chaque nouveau consommateur n'ajoute pas simplement du code O(1) ; Il ajoute également des tests de tableau de bord, d'alarme, de nouvelle tentative, de propriété et d'intégration. La meilleure frontière n’est donc pas celle qui produit le plus de services ; C'est la limite qui réduit réellement le coût du changement.

## Correspondances qui créent une fausse confiance```text
❌ Bounded Context = mikroservis
✓ Bounded Context önce dil, sahiplik ve model sınırıdır.

❌ Tek model = tutarlılık
✓ Her bağlamın kendi tutarlı modeli olabilir.

❌ Shared Kernel = yeniden kullanım
✓ Shared Kernel ortak değişim ve koordinasyon maliyetidir.

❌ REST çağrısı = entegrasyon stratejisi
✓ Sözleşme, sahiplik ve hata davranışı stratejidir.

❌ Eventual consistency = hata
✓ Doğru tasarlanırsa bağımsız iş akışının bilinçli trade-off'udur.

Liste de contrôle de conception stratégique

1. Où commencent les différentes significations d’un même mot ?
2. Les propriétaires de la langue, les propriétaires et les critères de réussite de chaque contexte sont-ils clairs ?
3. Cette limite peut-elle être vérifiée d'abord au sein du monolithe modulaire ?
4. Le modèle en amont infiltre-t-il directement votre domaine ? L’ACL est-elle requise ? Par exemple, dans le flux ERP → ACL → Shipping, CUST_TIER=7 doit être traduit dans le concept de fret DeliveryEligibility.
5. Le contrat partagé est-il rétrocompatible et versionné ?
6. Que se passe-t-il si le courtier plante après la validation de l'ordre ? Outbox écrit l'enregistrement et l'événement à publier dans la même transaction locale ; Lorsque le courtier relais revient, il réessaye en toute sécurité.
7. Existe-t-il des décisions produit et opérationnelles concernant le retard, la duplication et la relecture des événements ?

Le code n'augmente pas seulement de quelques lignes ; la surveillance, l'alarme, la nouvelle tentative et les frais généraux d'exploitation sont également ajoutés. Bien que l'incrément de code puisse sembler être O(1), le coût d'exploitation n'augmente pas de manière linéaire. Pas le nombre de services ; Mesurez l’interchangeabilité et l’isolation des erreurs.

Ce qu'il faut retenir de cet article

1. Il n’existe pas de modèle unique correct pour les grands systèmes ; Chaque contexte délimité porte sa propre réalité commerciale.
2. Les microservices ne sont pas le début de la frontière stratégique ; parfois c'est sa conséquence physique.
3. La cartographie contextuelle n'est pas le détail technique de l'intégration ; Le contrat rend visible la décision de protection de la puissance et du modèle.
4. L'événement et la boîte d'envoi sont utilisés pour maintenir en toute sécurité l'indépendance des contextes.

La limite architecturale est l'endroit où une décision est prise, dans quelle langue et sous la responsabilité de qui, avant que le code s'arrête.

Dans la dernière section, nous examinerons la durée de vie de production de DDD : Event Storming, transformation héritée, couche anti-corruption et déplacement des changements en toute sécurité.