Arquitectura Explícita: Buenas Prácticas de DDD para tu Empresa

Si alguna vez te has preguntado cómo organizar el código de una aplicación para que no se convierta en un spaghetti inmanejable, estás en el lugar correcto. La Arquitectura Explícita — un enfoque que unifica ideas de DDD, Arquitectura Hexagonal, Onion Architecture, Clean Architecture y CQRS — ofrece un mapa claro para estructurar software que crece sin volverse ingobernable.

Este artículo se inspira directamente en el trabajo de Herberto Graça y su artículo “DDD, Hexagonal, Onion, Clean, CQRS… How I put it all together”, adaptando esos conceptos a un lenguaje práctico para equipos empresariales.

Los tres bloques fundamentales

Toda aplicación, sin importar su tamaño, se compone de tres grandes bloques:

El núcleo de aplicación (Application Core): Es la lógica de negocio, el código que hace que tu software haga lo que debe hacer. Es lo más importante. No depende de la base de datos, ni del framework, ni de ninguna tecnología externa.
Los mecanismos de entrega (UI / Driving Side): Las interfaces de usuario — una web, una API, una app móvil, incluso una línea de comandos— que le dicen al núcleo qué hacer.
La infraestructura (Driven Side): La base de datos, servicios de email, APIs de terceros, buscadores… Herramientas que el núcleo utiliza para hacer su trabajo, pero que son reemplazables.

La regla de oro es simple: las dependencias apuntan siempre hacia adentro. El núcleo no sabe nada de la base de datos ni de la interfaz. La infraestructura y la UI dependen del núcleo, nunca al revés.

Puertos y Adaptadores: la conexión con el exterior

¿Cómo se comunica el núcleo con el mundo exterior sin acoplarse a él? La respuesta son los puertos y adaptadores:

Puertos: Son interfaces (contratos) definidas dentro del núcleo. Dicen qué necesita la aplicación, no cómo se consigue. Por ejemplo: “necesito guardar un cliente” → eso define un puerto IClientRepository.
Adaptadores primarios (Driving): Son los controladores, comandos de consola o endpoints de API. Toman la entrada del usuario, la traducen y llaman al núcleo a través de un puerto.
Adaptadores secundarios (Driven): Implementan los puertos del núcleo. Si el núcleo dice “necesito guardar un cliente”, el adaptador de MySQL o PostgreSQL es el que hace el trabajo real. ¿Quieres cambiar de base de datos? Solo creas un nuevo adaptador.

Organización interna: capas dentro del núcleo

Dentro del Application Core, Graça propone dos capas inspiradas en DDD:

Capa de Aplicación: Contiene los casos de uso (Application Services o Command Handlers). Orquestan la lógica: buscan entidades, ejecutan lógica de dominio y persisten resultados. Aquí también viven los puertos de infraestructura.
Capa de Dominio: Contiene las entidades, value objects, servicios de dominio y eventos de dominio. Es el corazón puro del negocio. No sabe nada de casos de uso ni de infraestructura.

Componentes: organiza por dominio, no solo por capa

Un error común es organizar el código solo por capas (una carpeta Controllers, otra Services, otra Repositories). Graça recomienda organizar por componentes (bounded contexts): agrupar todo lo relacionado con Facturación junto, lo de Usuarios junto, etc.

Cada componente es como un mini-sistema dentro de tu aplicación, con sus propias capas internas. Esto facilita escalar equipos, mantener el código y eventualmente migrar a microservicios si es necesario.

Dónde aprender esto bien: dos cursos que valen cada centavo

La teoría es necesaria, pero ver estos conceptos implementados paso a paso en código real es lo que marca la diferencia entre entender DDD y saber aplicarlo. Hay dos cursos en Udemy que, si estás en el ecosistema .NET, son simplemente increíbles:

ASP.NET Core Arquitectura Limpia de Felipe Gavilán es probablemente el curso en español más completo sobre Clean Architecture aplicada a .NET. Felipe no se limita a la teoría: construye una aplicación completa desde cero, capa por capa, explicando por qué cada decisión de diseño tiene sentido. Ver cómo crea el proyecto de dominio sin ninguna dependencia externa, cómo define los puertos (interfaces) y luego cómo los adaptadores de infraestructura los implementan, es exactamente lo que necesitas si quieres pasar de “entiendo el concepto” a “sé cómo se ve esto en un proyecto real”. Además, cubre CQRS con MediatR, validaciones con FluentValidation y testing unitario de la capa de dominio — todo dentro del mismo flujo de trabajo.

Clean Architecture de .NET University es el complemento perfecto. Donde el curso de Felipe brilla en la implementación práctica, este curso profundiza en los fundamentos arquitectónicos: qué es realmente una dependencia, por qué las flechas de dependencia deben apuntar hacia adentro, y cómo Clean Architecture se relaciona con Hexagonal, Onion y CQRS. Es más conceptual, pero no por eso menos práctico: también implementa una solución completa en .NET, pero pone especial énfasis en los principios detrás de cada capa. Si alguna vez te has preguntado “¿este código va en Application o en Domain?”, este curso te da la respuesta con ejemplos concretos.

¿Por qué ambos? Porque se complementan. El de Felipe Gavilán te enseña cómo construir una aplicación bien arquitectada en .NET, paso a paso, sin saltarse nada. El de .NET University te enseña por qué cada capa existe y qué pasa cuando rompes las reglas. Juntos forman una base sólidísima para cualquiera que quiera aplicar DDD y Clean Architecture en proyectos reales de empresa.

7 tips para implementar DDD y Arquitectura Explícita en tu empresa

Define los puertos desde el negocio, no desde la tecnología. Cuando crees una interfaz (puerto), piensa en qué necesita la aplicación, no en qué hace la base de datos. Un puerto como ObtenerPedidosDelMes() habla el lenguaje del negocio; EjecutarQuerySQL() habla el lenguaje de la infraestructura. El primero te permitirá cambiar de tecnología sin dolores de cabeza; el segundo te encadenará a ella.
Empieza por los bounded contexts, no por las capas técnicas. Antes de escribir una línea de código, identifica los subdominios de tu negocio: ¿Cuáles son las áreas conceptuales? ¿Facturación, Inventario, Usuarios, Reportes? Organiza tu código en torno a esos componentes primero. Las capas técnicas (Application, Domain, Infrastructure) van dentro de cada componente, no al revés.
Aisla el dominio como un tesoro. La capa de dominio no debe tener dependencias externas: ni paquetes de ORM, ni librerías de logging, ni referencias al framework. Si tu entidad Pedido importa algo de Entity Framework, tu dominio ya está acoplado. Usa interfaces (puertos) para todo lo que venga de fuera y mantén el dominio puro y testeable de forma aislada.
Desacopla componentes con eventos, no con llamadas directas. Si el componente de Facturación necesita reaccionar cuando se completa un Pedido, no llames directamente de uno al otro. Usa eventos de dominio o de aplicación. El componente de Pedidos emite un evento PedidoCompletado; Facturación escucha y reacciona. Así, los componentes evolucionan de forma independiente y puedes añadir nuevos comportamientos sin modificar los existentes.
Sé pragmático: no apliques todos los patrones desde el día uno. DDD y Arquitectura Explícita son guías, no dogmas. En un proyecto pequeño, un solo bounded context puede ser suficiente. No necesitas CQRS si tu equipo es de dos personas y el dominio es simple. Aplica la complejidad gradualmente, cuando el dolor del crecimiento la justifique. Como dice Graça: “Estos son lineamientos. La aplicación es el territorio, y eso es lo que define la arquitectura real”.
Aprende haciendo, no solo leyendo. La teoría de DDD y Clean Architecture es fascinante, pero hasta que no escribes código siguiendo estas capas, no internalizas los principios. El curso de Felipe Gavilán es ideal para esto: lo sigues línea por línea, rompes cosas, las arreglas y entienes por qué cada capa está donde está. No subas el vídeo de velocidad; escribe el código tú mismo. La diferencia entre “lo leí” y “lo construí” es abismal.
Cuestiona cada dependencia que cruce capas. Si el proyecto de Infrastructure referencia a Domain directamente en lugar de a Application, algo va mal. Si Domain importa Entity Framework, algo va peor. Cada vez que añadas un using o una referencia de proyecto, pregúntate: “¿Esta dependencia apunta hacia adentro?”. Si la respuesta es no, es un acoplamiento que te dolerá mañana. Los cursos mencionados arriba muestran cómo configurar las dependencias de proyecto correctamente en .NET — y eso solo ya vale la inversión.

La receta en pocas palabras

Concepto	¿Qué significa?
Application Core	La lógica de negocio pura. No depende de nada externo.
Puertos	Interfaces definidas por el negocio.
Adaptadores	Implementaciones concretas (MySQL, SendGrid, REST API).
Capa de Aplicación	Casos de uso que orquestan la lógica.
Capa de Dominio	Entidades, value objects y reglas puras del negocio.
Componentes	Agrupación por subdominio (Facturación, Usuarios, etc.).

Aplicar estos principios no es solo una cuestión técnica: es una decisión de negocio. Un código bien estructurado se traduce en menos bugs, entregas más rápidas y equipos más autónomos. Y en una empresa, eso es competitividad real.

Arquitectura Explicita: Buenas Practicas de DDD para tu Empresa