Cuando nos referimos al DDD, generalmente esto irá de la mano con una implementación de software en N capas, de tal manerea que la lógica de negocio recaerá completamente en una capa del backend (backend - parte que interactúa directamente con el servidor web o de aplicación "distinto a la vista"), esto con la intención de gestionar de mejor manera la lógica misma, en un punto centralizado, y que los cambios dependan más solo de esa capa, sin darle carga lógica al resto de capas de una aplicación de software.
Flujo de trabajo del DDD en N capas
Para entender de mejor manera la distribución lógica de las capas en una aplicación de este tipo, seguidamente se incorpora un gráfico que describe el flujo de trabajo de esta:
Se debe entender que esta representación es un diseño propio de nuestra forma de implementación en Codideep, ya que el DDD en N capas se podría implementar de diversas maneras, sin embargo, en este gráfico se muestra el Business Layer como capa pricipal de negocio, lo que podría estar conformado por varias subcapas, además que se incorporan algunas tecnologías de forma descriptiva para tener un mejor endimiento de esta implementación.
Por otra parte, si eres conocedor del tema, podrás identificar que en esta representación gráfica, también se está incorporando otros patrones de diseño, por ejemplo: MVVM y DAO, sin embargo, en la explicación de este post, le daremos un mayor enfoque al DDD).
Entendido lo anterior, pasemos a describir cada capa, de forma breve y concisa (para esta sección, en algunas partes se tomará como referencia al MVC, por tanto, se puede revisar el siguietne post, para tener una mayor comprensión: https://codideep.blogspot.com/2025/05/desarrollo-de-software-i-patron-de.html).
Capa de presentación (Presentation layer)
Si observamos cuidadosamente esta capa, veremos que se parece mucho al MVC que se vió en un artículo previo, sin embargo, no nos dejemos llevar, ya que en esta capa se estaría implementando un framework como Angular, React, Vue, etc. (esto no es obligatorio, pero si recomendable), ya que será la capa para presentar la información, pero por su desacoplamiento, es mucho más que una capa de vista de un simple MVC.
Ahora, veamos brevemente cada uno de sus componentes internos:
View: Esta es una subcapa donde se maneje concretamente el código HTML y CSS.
Controller: Esta capa será la lógica en un nivel muy simple de la parte de la vista, pero espera ¿No que la lógica debe recaer en una capa del backend como dijimos antes, para el DDD?, pues, esto es cierto; sin embargo, esta lógica no se trata de la lógica de negocio en sí, sino más bien de la lógica de interacción del usuario, con los botones, campos desplegables, campos de entradas y otros elementos similares, al alcance del usuario final, es decir.
Service: En el contexto de la capa de presentación y concretamente para este ejemplo, un componente llamado "Service" de Angular, es aquella subcapa que se encarga de interactuar con los endpoints (servicios web que exponen funciones del backend); en palabras simples, será el nexo entre el backend y frontend.
Capa de servicios (Service layer)
Este es un término que en realidad no es usado de manera formal (la capa de servicios), sin embargo, por su propia naturaleza, en Codideep decidimos llamarlo de esta manera, ya que es aquella capa que expone los servicios creados en el backend, generando así la conexión entre backend y frontend, pero, considerando que esta capa de servicios es diferente a la subcapa de servicios mencionada anteriormente; sin emabargo, no por nada tienen nombres similares, mientras que uno expone lo servicios (capa de servicios en el backend) el otro consume dichos servicios (subcapa de servicios en la capa de presentación).
Controller: En este caso es una clase que hará de orquestador entre las peticiones de la capa de presentación y el enlace con el backend de la aplicación (si leyeron el artículo de MVC mencionado más arriba, verán que se aclaró justo este concepto, que el controlador significaba una cosa en el MVC, pero aquí "en el DDD", toma un rol completamente diferente).
Service object: Este es otro concepto que lo aplicamos en Codideep; si quisiéramos acercarlo a un concepto formal, este sería muy semejando a los ViewModel, entonces, porque llamarlo Service object y no ViewModel; simple, es un término que consideramos más apropiado en la naturaleza del flujo de DDD y más aún en un contexto web. Aclarado lo anterior, esta no es más que una clase compuesta por otras clases (de ser necesario) que transportan los datos entre el backend y frontend y viceversa.
Capa de negocio (Business layer)
Llegamos al core de esta publicación, esta es la capa donde debería recaer toda la lógica empleada en el software que implementa este patrón, pues el DDD, tiene como propósito centralizar la lógica en una capa y subcapas, que se encarguen de las validaciones, conexiones externas, pre-acceso a datos y demás.
Business logic: Esta es la clase principal (claro, viéndolo en singular, ya que en realidad serán varias clases por cada entidad de negocio), es donde se gestionará la lógica principal de la aplicación y toda la responsabilidad funcional del negocio como tal.
Validations: Esta también será un conjunto de clases donde se separará la validación de datos y negocio, de tal manera que la clase principal se enfoca en la lógica propiamente dicha, y las clases de validación a lo suyo, y esto es, validar los datos y el negocio por separado, ejemplo: validación de formatos, validación de existencias, validación de duplicidad, etc.
Service: ¿Ya te cansaste de de ver este término? pues aquí también tiene un propósito diferente, aunque un comportamiento funcional similar a los anteriores; esta clases o clases se encargarán de contectar con servicios externos al sistema central, por ejemplo: acceso a API's como RENIEC, SUNAT, SUNARP, etc.
Import of catalogs: Estas clases, en la capa de negocio, se encargarán de definir la conexión entre la capa misma de negocio y las funciones que expongan la recuperación, persistencia o eliminación de datos (la instancia para el acceso a dichas funciones, convenientemente serán implementadas a través de inyecciones de dependencia).
Capa de transferencia de datos (Data transfer layer)
En esta capa se definen objetos encapsulados, los conocidos DTO's (Objetos de transferencia de datos); su rol es el trasladar información de capa a capa, pasando entre ellas como parámetros de entrada o salida bajo funciones definidas por cada clase de cada capa.
Capa de repositorios (Repository layer)
En esta capa se definen interfaces (no, no interfaces gráficas, más bien, contratos entre clases), y ¿qué es esto? pues, son definiciones que especifican las funciones que se implementarán en una clase, y que por otro lado, se consumiran en otras clases.
Estas interfaces determinarán el contrato que existirá entre la capa de negocio y la capa de acceso a datos, es como un catálogo (pensando en una revisata) "la interface" que ofrece prendas y el cliente quien consume lo ofrecido por este catálogo "el usuario que compra".
Capa de acceso a datos (Data access layer)
Muchas veces confundida con la capa de datos, pero no, no son lo mismo. Esta capa es donde se genera la conexión a la base de datos, se aplican las consultas para persistencia, eliminación o recuperación de datos, y a su vez, será donde se implementen las interfaces de la capa de repositorio.
Export of catalog: Interfaces que se implementan en las clases de consultas, para exponer como catálogo aquellas funciones definidas, para su difusión, mediante al capa de repositorio.
Queries: Clases donde se implementa las interafaces definidas para el catálogo, además, aquí es donde se hace todo el código SQL que interactúa con la base de datos, o en su defecto, se hace uso de ORM's o framework's de acceso a datos, abstrayendo así completamente la parte del SQL.
Entities: Similares a los modelos en el MVC, sin embargo, aquí son netamente clases encapsuladas que hacen de espejo de las tablas de base de datos ¿y dónde está la diferencia con los modelos? pues, realmente no existe mucha diferencia si lo vemos desde el enfoque de MVC o DDD.
Connection: Clase encargada estrictamente de la conexión con la base de datos.
Capa de datos (Data layer)
Diremos que esta capa no es concretamente parte del DDD, sin embargo, su presencia es más que clara y necesaria, esta vendría a ser con precisión el almacén de datos, es decir, donde se guarda toda la información, pueden ser ficheros, gestores de bases de datos, archivos JSON, archivos XML o similares.
CONCLUSIÓN
Habiendo abarcado el concepto de DDD, se espera dejar claro la distribución de capas de este, sin embargo, debemos entender que cada autor puede definir este patrón de diseño de diferentes maneras (rigiéndose en que la lógica recae en el dominio de la aplicación, pero el número de capas, la distribución de clases y forma general de trabajo, puede variar mucho, ya que no existe una regla exacta para esta implementación).
El DDD es un patrón ampliamente usado, especialmente para proyectos de gran embergadura con gran cantidad de personas trabajando en este (desarrolladores y/o programadores), ya que logra un desacoplamiento lógico de las capas, de tal manera que pueden trabajar varias personas en un mismo proyecto, sin generar conflictos a nivel de código o al menos disipando en gran medida estos, sin embargo, esta, al igual que el MVC, suele manejar una arquitectura monolítica, lo que no es muy eficiente para proyectos de muy alta concurrencia, y ¿qué quiere decir esto? pues, eso queda como tarea para enriquecer vuestros conocimientos con un poco más de lectura ¿la solución a esto? pues, lo veremos en pubilcaciones posteriores.
- Debes estar logueado para realizar comentarios