DDD: diseño de software para la empresa, no para la base de datos (Ddd Diseno DE Software Para La Empresa No Para La Base DE Datos)

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.

El primer problema: ¿por qué el código pierde el lenguaje del negocio?

En los primeros días de un producto, suele ser sencillo: dibujar la tabla, escribir el punto final, agregar el registro. Este enfoque no está mal. Sin embargo, cuando proliferan las reglas de precios, devoluciones, riesgos, entrega y autorización, el valor del sistema no está en las tablas; De ello depende la correcta implementación de estas decisiones.```text Veritabanı → Table → CRUD → Service katmanı → dağınık iş kuralları

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

## Conceptos en la primera mención```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` es más que una llamada técnica: transmite la intención de realizar un pedido. Cuando tiene éxito, `OrderPlaced` se convierte en un hecho comercial. Si los nombres no transmiten el idioma de la empresa, el equipo los vuelve a traducir con cada nueva característica.

## 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.

¿Por qué CRUD funciona muy bien durante largos períodos de tiempo?

Si el equipo es pequeño, el producto es singular y las reglas son pocas, el flujo Controller → Service → Repository → Database es rápido y sencillo. Para pantallas de registro simples, paneles de administración y prototipos de corta duración, esta simplicidad es una ventaja real. DDD no es una ideología contra CRUD.

La ruptura no ocurre cuando se agregan más registros a la misma tabla; Comienza cuando el mismo modelo tiene que representar diferentes intenciones comerciales. Un Order se utiliza para promoción, impuestos, descuento, devolución, reserva de stock, entrega y control de riesgos a la vez.```text Database-first OrderRow → status = 2 → UpdateOrderStatus()

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

## Lenguaje común: abolir el impuesto de traducción

Si el experto en negocios dice “cliente preferido” y el código dice `UserStatus = 1`, el sistema tiene dos realidades diferentes. Esta diferencia provoca que el nuevo miembro del equipo no entienda bien, la regla se repite en diferentes servicios y las reuniones se convierten en constantes sesiones de explicación.```text
❌ InsertNewSchoolYear()
✓ OpenNewSchoolYear()

❌ UserStatus = 1
✓ customer.MarkAsPreferred()

❌ OrderRow
✓ LoanApplication / Order / Subscription
```El lenguaje común no consiste en sustituir cada nombre técnico por un término comercial. El modelo debe ser lo suficientemente preciso para explicar las decisiones en ese contexto. Así como el mapa no muestra el mundo entero, sino la realidad requerida para el viaje; El modelo de dominio representa la decisión comercial relevante, no todos los datos.

## Modelo anémico: hacer de los datos un objeto y el comportamiento un procedimiento

El modelo de dominio incruento es una estructura en la que las clases de servicios gestionan entidades llenas de entidades públicas. `OrderService`, `PricingService`, `DiscountService` y `ShipmentService` comienzan a aplicar las mismas reglas en diferentes lugares a lo largo del tiempo. El objeto sólo transporta datos; el comportamiento queda fuera.```text
❌ order.Status = Paid
❌ order.Total = -10

✓ order.ConfirmPayment(payment)
✓ order.ApplyDiscount(discount)
```El propósito del modelo rico no es poner todo en una sola entidad. Pero significa mantener las reglas del sistema, que nunca deben romperse, junto con el comportamiento. Por ejemplo, un pedido no se puede enviar hasta que se verifique el pago. Sólo debe haber un propietario de esta regla.

## El costo y el contexto correcto de DDD

DDD; Requiere análisis, sesiones de lenguaje común, denominación más cuidadosa y disciplina de equipo. Este costo no se amortiza con la simple entrada de datos. La decisión no se tomó con entusiasmo técnico; Debe tomarse en cuenta la complejidad del dominio y la tasa de cambio.

| Señal | CRUD es más conveniente | La inversión en DDD tiene sentido |
| --- | --- | --- |
| Regla de negocio | Bajo y estable | En capas, crítico, en constante cambio |
| Vida del producto | Prototipo corto | Producto de larga duración |
| Coste del error | Bajo | Financiera u operativamente alta |
| Charla en equipo | Unívoco | Un mismo concepto tiene diferentes significados |

A medida que aumenta el número de reglas, el coste de funcionamiento de la solución suele ser no lineal. Cuando una regla `k` se repite en un servicio diferente, el costo del cambio es al menos O(k); Los casos de prueba crecen más rápido si las reglas se influyen entre sí. DDD no hace que mágicamente este costo sea cero; Hace visibles la propiedad y los límites.

## Primer paso: observar el lenguaje, no reescribir el código

1. Elija el flujo de trabajo donde se toman las decisiones más costosas.
2. Registre los verbos y sustantivos utilizados por el profesional de negocios.
3. Aclarar términos conflictivos en un solo contexto.
4. Modele el nuevo comportamiento como una intención comercial en lugar de una actualización de un campo de datos.
5. Incluir únicamente comportamientos que impidan el estado inválido en este límite.

En este proceso, la base de datos, el marco y la API son los adaptadores; No es propietario de la decisión de dominio.

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

Lista de verificación de decisiones

• ¿Qué norma se infringe cuando se produce el error empresarial más costoso?
• ¿El experto en negocios y el código se refieren al mismo concepto con la misma palabra?
• ¿Es status = 2 un cambio de estado o un comportamiento comercial significativo?
• ¿Existe un único titular de la norma? ¿O se repite en diferentes servicios?
• ¿Es este ámbito lo suficientemente complejo como para que el coste del análisis se amortice a largo plazo?

Si no hay una respuesta clara a estas preguntas, no elija primero la entidad o el marco. Primero aclare el problema, el lenguaje y los límites.

Lo que debes recordar de este artículo

1. DDD no está en contra de la base de datos; Es un enfoque de diseño que reconoce que las reglas comerciales son más valiosas que los datos.
2. Lenguaje común, no notas de reuniones; Es un contrato de código, API y decisiones.
3. El modelo incruento magnifica el riesgo de estados no válidos al distribuir el comportamiento a la capa de servicio.
4. DDD no está en todos los proyectos; Donde la complejidad y el cambio generan costos, la inversión regresa.

El valor del software no está en almacenar datos; La capacidad de mantener las decisiones correctas del trabajo durante mucho tiempo.

En la siguiente sección llevaremos esta mentalidad al nivel del código: objeto de valor, entidad y límites agregados.

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.