¿Cómo funciona DDD en sistemas grandes? (Como Funciona Ddd EN Sistemas Grandes)

Primero dejemos la pregunta equivocada

El primer día solo había un modelo Book. Luego, el equipo de ventas solicitó un precio, el equipo de envío solicitó una ventana de entrega y agregó información de la campaña de marketing. Seis meses después, la misma aula se convirtió en un objeto que nadie entendía del todo. El problema no es que el libro esté creciendo; Se cargaron diferentes intenciones comerciales en un solo modelo.

Dividir un sistema grande en microservicios no es implementar DDD. Primero, es necesario entender qué partes del negocio tienen diferentes lenguajes, decisiones y ritmos de cambio. De lo contrario, producirá un monolito distribuido más caro en lugar de un monolito.```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

## Conceptos en la primera mención```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.
```La explicación simple de la Ley de Conway es la siguiente: así como la organización se comunica, el software refleja esa estructura a lo largo del tiempo. Bounded Context no es un microservicio; En primer lugar, puede vivir como un idioma, una propiedad y un código separados dentro de un monolito modular.

## Panorama general```text
                         Şirket
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
    Katalog              Satış                Kargo
       │                    │                    │
     Book               Customer             Recipient
       │                    │                    │
       └──────── OrderConfirmed event ────────┘
                            │
                         Outbox
                            │
                          Broker
                            │
                     Delivery projection
```Este diagrama no incluye el número de servicios físicos; Muestra en qué frontera viven el lenguaje, la propiedad y el cambio.

## ¿Por qué se interrumpe la búsqueda del único modelo verdadero?

En un catálogo de libros, es el título, el autor y el ISBN; en préstamo, es la copia física en la estantería; SKU y precio están a la venta. Combinarlos todos en una clase `Book` no es reutilizarlos, sino más bien unir diferentes intenciones. La misma tensión se observa para `Customer`: el equipo de ventas solicita información de crédito y facturación, mientras que la carga solo solicita dirección y preferencias de entrega.```text
❌ Unified Customer
creditLimit + invoiceAddress + deliveryWindow + marketingConsent + ...

✓ Sales.Customer
creditLimit + billingProfile

✓ Shipping.Recipient
deliveryAddress + deliveryWindow
```El problema no es la cantidad de objetos. Es la modificación de un mismo modelo por diferentes equipos por distintos motivos. Este costo de cambio se vuelve al menos O(k) a medida que aumenta el número de contextos afectados `k`; Cuando proliferan las dependencias, los costos de prueba y coordinación crecen más rápido.

## Contexto limitado: primero dibuje el límite con el idioma del trabajo

No mire las capas técnicas o las tablas de bases de datos para detectar el límite. Esté atento a estas señales:

1. ¿La misma palabra significa cosas diferentes en la reunión?
2. ¿Se multiplican casos especiales como `if (shipping)`, `if (sales)` en un modelo?
3. ¿Los equipos se esperan constantemente unos a otros para el mismo cambio?
4. ¿No están claros la propiedad de un dominio, la medida del éxito y el ritmo del cambio?

La Ley de Conway es una advertencia aquí: los límites de comunicación del sistema a menudo reflejan la forma en que se comunica la organización. Si se espera que un equipo tome decisiones independientes, el modelo y el límite de implementación de ese equipo deben ser lo más independientes posible. Este no es un objetivo técnico, sino una decisión de propiedad.

## Comience en Monolith; ver microservicio como resultado

La forma de menor riesgo de verificar el contexto acotado es con un monolito modular. El contexto tiene sus propios componentes de aplicación/dominio/infraestructura, acceso a datos y contrato explícito; pero aún no asume el costo operativo de las llamadas distribuidas.```text
Catalog module ── published contract ──► Sales module
Sales module   ── domain event ─────────► Shipping module

Her module: kendi dilini, use case'lerini ve sahipliğini korur
```Migrar a microservicios solo tiene sentido cuando existe una necesidad comprobada, como escalamiento independiente, implementación independiente, límites de seguridad diferentes o verdadera autonomía del equipo. Contexto limitado = La igualdad de microservicios es la razón más común para la implementación temprana.

## Mapeo de contexto: la integración no debería ser una coincidencia

La relación entre contextos está determinada por el equilibrio de poder y la contaminación del modelo, no por los puntos finales de API.

| Estado | Estrategia adecuada | Por qué |
| --- | --- | --- |
| Modelo heredado caótico | LCA | Evita que el lenguaje externo se filtre al dominio |
| Un gran número de consumidores | Servicio de host abierto + Idioma publicado | Comparte el contrato versionado, no el modelo interno |
| No tienes influencia aguas arriba, el modelo está limpio | Conformista | No instala capas de traducción innecesarias |
| Pieza común pequeña y rara vez modificada | Kernel compartido, último recurso | Acepta costo de coordinación |

En el ejemplo de ACL, el contexto de carga convierte el campo `CUST_TIER=7` del ERP heredado en su propio concepto `DeliveryEligibility`. El término ERP no entra dentro del ámbito de la carga. Esta capa es el costo del código adicional; A cambio, cuando el sistema externo cambia, el efecto permanece en un único punto de traducción.

## Evento, Bandeja de salida y coherencia final

Un contexto no debe leer la base de datos de otro contexto. Cuando ventas confirma un pedido, puede emitir el evento `OrderConfirmed`; cargo genera su propia vista de entrega a partir de esto. El evento no prohíbe por completo las llamadas sincrónicas; pero reduce la dependencia temporal en el flujo de trabajo independiente.```text
Sales transaction
  → Order'ı kaydet
  → Outbox'a OrderConfirmed yaz
  → Commit

Relay → Broker → Shipping consumer → Delivery projection
```Se requiere la bandeja de salida porque el corredor y la base de datos no comparten la misma transacción ACID. Si hay un registro de pedido, también hay un evento a transmitir; El relé puede volver a intentarlo. El consumidor debe ser idempotente porque puede recibir eventos duplicados. La consistencia final no es un error, sino una ventana de tiempo visible que el producto debe aceptar.

## El precio de este diseño.

Los límites del contexto requieren más acuerdos, observabilidad, control de versiones y disciplina de equipo. Cada nuevo consumidor no sólo agrega el código O(1); También agrega pruebas de panel, alarma, reintento, propiedad e integración. Por tanto, la mejor frontera no es la que produce más servicios; Es el límite lo que realmente reduce el coste del cambio.

## Coincidencias que crean falsa confianza```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.

Lista de verificación de diseño estratégico

1. ¿Dónde comienzan los distintos significados de una misma palabra?
2. ¿Están claros los dueños del lenguaje, dueños y criterios de éxito de cada contexto?
3. ¿Se puede verificar este límite primero dentro del monolito modular?
4. ¿El modelo ascendente se infiltra directamente en su dominio? ¿Se requiere ACL? Por ejemplo, en el flujo ERP → ACL → Shipping, CUST_TIER=7 debe traducirse al concepto de carga DeliveryEligibility.
5. ¿El contrato compartido es compatible con versiones anteriores y tiene versiones?
6. ¿Qué sucede si el corredor falla después de que se confirma la orden? Outbox escribe el registro y el evento que se publicará en la misma transacción local; Cuando el intermediario de retransmisión regresa, lo vuelve a intentar de forma segura.
7. ¿Existen decisiones operativas y de producto para retrasar, duplicar y reproducir eventos?

El código no sólo aumenta unas pocas líneas; También se agregan monitoreo, alarma, reintento y gastos generales de operación. Aunque el incremento del código puede parecer O(1), el costo de operación no crece linealmente. No la cantidad de servicios; Mida la intercambiabilidad y el aislamiento de errores.

Lo que debes recordar de este artículo

1. No existe un modelo único correcto para sistemas grandes; Cada contexto acotado conlleva su propia realidad empresarial.
2. Los microservicios no son el comienzo de la frontera estratégica; a veces es su consecuencia física.
3. El mapeo de contexto no es el detalle técnico de la integración; El contrato hace visible la decisión de protección de potencia y modelo.
4. Evento y Bandeja de salida se utilizan para mantener de forma segura la independencia de los contextos.

El límite arquitectónico es donde se toma una decisión, en qué idioma y bajo quién es la responsabilidad, antes de donde se detiene el código.

En la última sección, examinaremos la vida útil de DDD: Event Storming, transformación heredada, capa anticorrupción y cambio seguro.