{"id":38398,"date":"2023-12-07T11:00:12","date_gmt":"2023-12-07T10:00:12","guid":{"rendered":"https:\/\/www.hiberus.com\/crecemos-contigo\/?p=38398"},"modified":"2024-01-12T11:30:53","modified_gmt":"2024-01-12T10:30:53","slug":"domain-driven-design-como-disenar-agregados-en-el-marco-ddd","status":"publish","type":"post","link":"https:\/\/www.hiberus.com\/crecemos-contigo\/domain-driven-design-como-disenar-agregados-en-el-marco-ddd\/","title":{"rendered":"C\u00f3mo dise\u00f1ar agregados en el marco Domain Driven Design"},"content":{"rendered":"

Si has llegado a este art\u00edculo a trav\u00e9s de una b\u00fasqueda org\u00e1nica, es razonable asumir que ya posees una s\u00f3lida base de conocimientos en varios aspectos fundamentales para entender c\u00f3mo dise\u00f1ar eficientemente un agregado<\/strong>. Es m\u00e1s, es muy probable que ya est\u00e9s versado en conceptos cruciales como el Contexto Delimitado, los Submodelos, las Entidades y los Objetos de Valor, entre otros. Estos t\u00e9rminos, pilares fundamentales de la arquitectura de software<\/strong>, son esenciales para entender correctamente c\u00f3mo dise\u00f1ar agregados en el marco del Domain Driven Design (DDD)<\/strong>.<\/p>\n

Sin embargo, si estos t\u00e9rminos te son ajenos porque eres un lector frecuente de nuestro blog, pero a\u00fan no has tenido la oportunidad de familiarizarte con estos conceptos, no te preocupes. En este art\u00edculo tomaremos el tiempo para explicar brevemente qu\u00e9 es cada uno de ellos, c\u00f3mo se utilizan en el contexto del dise\u00f1o de software y, sobre todo, c\u00f3mo pueden ayudarte a desarrollar sistemas m\u00e1s robustos, escalables y mantenibles<\/strong>. As\u00ed, tanto si eres un veterano en estas materias como si est\u00e1s dando tus primeros pasos, este art\u00edculo pretende aportarte una visi\u00f3n m\u00e1s clara y profunda de lo que implica un buen dise\u00f1o de agregado en DDD.<\/p>\n

T\u00e9rminos que debes conocer para dise\u00f1ar agregados en el marco Domain Driven Design<\/h2>\n

Value Objects<\/h3>\n

Primero, hablemos de los Objetos de Valor (Value Objects)<\/strong>. En el Domain Driven Design, un Objeto de Valor es una pieza diminuta pero crucial del modelo de dominio<\/strong>, que contiene atributos<\/strong>, pero no tiene una identidad individual. Usualmente son inmutables y se comparan seg\u00fan el estado que contienen y no por una identidad. Ejemplos comunes de Objetos de Valor pueden ser un correo electr\u00f3nico, una contrase\u00f1a o una direcci\u00f3n.<\/p>\n

Bounded Contexts<\/h3>\n

A continuaci\u00f3n, tenemos los Contextos Delimitados (Bounded Contexts)<\/strong>, que es un t\u00e9rmino esencial para definir las fronteras de los distintos modelos de dominio de una aplicaci\u00f3n<\/strong>. Un Contexto Delimitado es la definici\u00f3n de un espacio donde un modelo en particular aplica y tiene sentido. Suele encapsular un subdominio de la l\u00f3gica del negocio y se utiliza para dividir un sistema grande y complejo en subsistemas m\u00e1s manejables.<\/p>\n

Entities<\/h3>\n

En conjunto con estos conceptos, encontramos otro muy familiar para cualquier desarrollador: las Entidades<\/strong>. Las Entidades se distinguen por tener una identidad \u00fanica y consistente<\/strong>, a diferencia de los Objetos de Valor. Cada instancia de una entidad se caracteriza por su individualidad innegociable<\/strong>. Su identidad se mantiene constante a lo largo de su vida \u00fatil, incluso si sus atributos pueden variar. Por ejemplo, en el contexto comercial, cada producto o cada cliente posee caracter\u00edsticas que lo distinguen de los dem\u00e1s y, por tanto, cada uno de ellos puede considerarse una entidad. El hecho de que cada producto tenga su identificador \u00fanico o que cada cliente pueda ser identificado por su correo electr\u00f3nico ilustra el car\u00e1cter individual y perpetuo que define a las entidades<\/p>\n

Submodels<\/h3>\n

Finalmente, los Submodelos<\/strong> son partes del sistema que representan un detalle o aspecto espec\u00edfico y necesario del modelo dentro de un Contexto Delimitado<\/strong>. Permiten dividir un sistema en partes de menor tama\u00f1o<\/strong>, y por lo tanto m\u00e1s f\u00e1ciles de administrar y entender.<\/p>\n

Aggregate<\/h3>\n

Todos los anteriores elementos no son m\u00e1s que bloques de construcci\u00f3n que mejoran la escalabilidad, mantenibilidad y cohesi\u00f3n de la arquitectura de software<\/strong>. Ahora que hemos establecido una base s\u00f3lida, podemos regresar a nuestro tema principal, el dise\u00f1o de agregados.<\/p>\n

Si el Domain Driven Design (DDD) nos ha introducido un concepto nuevo, ese es el de \u00abagregado\u00bb. Antes de explicar c\u00f3mo dise\u00f1arlo, conviene profundizar en por qu\u00e9 resulta ventajoso considerar el uso del modelo de agregado.<\/p>\n

El primer aspecto a tener en cuenta es el del encapsulamiento<\/strong>. Un AggregateRoot garantiza la coherencia de un dominio y su integridad<\/strong> al encapsular y agrupar entidades y objetos de valor relacionados. Este grupo de entidades afines facilita significativamente la interacci\u00f3n con los mismos<\/strong> como una unidad cohesiva.<\/p>\n

En adici\u00f3n, la utilizaci\u00f3n de agregados puede simplificar enormemente el Modelo del Dominio<\/strong>. Al tratar conglomerados de entidades y objetos de valor relacionados como una entidad \u00fanica, se reduce la complejidad del modelo<\/strong>. Este enfoque permite a los desarrolladores centrarse m\u00e1s en la l\u00f3gica del negocio.<\/p>\n

En lo referente a la l\u00f3gica del negocio, los agregados contribuyen a aislar las Reglas del Negocio<\/strong>. Las reglas y l\u00f3gica del negocio quedan encapsuladas dentro de un AggregateRoot<\/strong>, generando por tanto una protecci\u00f3n de la coherencia en el contexto de las reglas de negocio<\/strong>.<\/p>\n

Desde el punto de vista de la gesti\u00f3n de persistencia, los AggregateRoots pueden representar una transacci\u00f3n de base de datos<\/strong>. Esta correspondencia puede simplificar el manejo de la persistencia<\/strong>, facilitando a su vez la gesti\u00f3n de las operaciones de las bases de datos<\/strong>.<\/p>\n

Puntos clave para dise\u00f1ar agregados en el marco Domain Driven Design<\/h2>\n

Habiendo comprendido el panorama general en torno al agregado y las razones por las cuales deber\u00edamos emplearlos, procedamos a analizar cu\u00e1les son los aspectos esenciales para estructurar el agregado id\u00f3neo para nuestros subm\u00f3dulos.<\/p>\n

Persistencia<\/h3>\n

Aunque no todos los subm\u00f3dulos est\u00e1n orientados a la persistencia<\/strong> \u2013podemos tener un subm\u00f3dulo, por ejemplo, que simplemente realiza una solicitud CURL para enviar datos fuera de nuestro ecosistema\u2013, aquellos que s\u00ed implican persistencia deben considerar que todos sus cambios son de naturaleza transaccional<\/strong>. Esto significa que, al momento de persistir, tendremos que almacenar el objeto completo en cada ocasi\u00f3n dentro del respectivo subm\u00f3dulo o contexto. La integridad transaccional<\/strong> es una de las grandes ventajas de este enfoque, ya que asegura que los datos almacenados est\u00e9n siempre en un estado consistente<\/strong>. Adem\u00e1s, esto nos libera de tener que escribir c\u00f3digo adicional para manejar las posibles inconsistencias de datos<\/strong>, simplificando as\u00ed todav\u00eda m\u00e1s la l\u00f3gica del negocio.<\/p>\n

Invariantes<\/h3>\n

Los agregados<\/strong> tienen un papel vital en la preservaci\u00f3n de las reglas de negocio y en la garant\u00eda de la consistencia en nuestro dominio<\/strong>. Una forma en que los agregados realizan esta tarea es a trav\u00e9s de la gesti\u00f3n de las invariantes del negocio<\/strong>.<\/p>\n

Las invariantes del negocio<\/strong> son condiciones o reglas que siempre deben cumplirse, no importa cu\u00e1ndo ni d\u00f3nde se vean en el ciclo de vida de un objeto de dominio. En otras palabras, son verdades que siempre son v\u00e1lidas para un conjunto de entidades<\/strong>. Estos se mantienen a trav\u00e9s de las transacciones, lo que significa que cuando una transacci\u00f3n se completa, todas las invariantes en los agregados afectados se cumplen.<\/p>\n

Por ejemplo, un \u00abArt\u00edculo\u00bb que tiene \u00abValoraciones\u00bb, una invariante de agregado podr\u00eda ser, en este caso, hacer la media de las valoraciones. Esta es una propiedad derivada (es decir, se calcula en base a otros atributos o entidades) que quiere persistirse para evitar c\u00e1lculos repetitivos. As\u00ed, cada vez que se agrega o elimina una valoraci\u00f3n, se actualiza esta invariante para mantener la coherencia. Por lo tanto, en lugar de tener que hacer la media de las valoraciones cada vez que se necesita saber, se conserva y actualiza este valor como una propiedad del agregado ‘Art\u00edculo’.<\/p>\n

Este enfoque optimiza en gran medida la eficiencia del sistema al reducir la necesidad<\/strong> de ejecutar c\u00e1lculos redundantes<\/strong>. Sin embargo, la implementaci\u00f3n de esta invariante de agregado plantea un desaf\u00edo esencial: garantizar la sincronizaci\u00f3n continua entre este valor pre-calculado y los datos relacionados actuales<\/strong>.<\/p>\n

Resulta pertinente reafirmar que la persistencia de invariantes de agregado puede simplificar de manera notable la recopilaci\u00f3n de informaci\u00f3n derivada<\/strong>, incrementando al mismo tiempo la eficiencia del sistema<\/strong> al evitar c\u00e1lculos innecesarios. A fin de definir de manera \u00f3ptima el agregado, conviene pre-calcular la mayor cantidad de datos posible. No obstante, esta t\u00e9cnica puede originar una incongruencia temporal en los datos, y es responsabilidad del negocio decidir si dicha incongruencia puede tolerarse por un periodo determinado o si debe rectificarse inmediatamente dentro del agregado, actualiz\u00e1ndose cada cierto tiempo o tras cada cierto n\u00famero de eventos acumulados. Un ejemplo com\u00fan de esta situaci\u00f3n es el recuento de suscriptores en un video de YouTube, que a menudo demora algunos segundos en actualizarse.<\/p>\n

En plataformas a gran escala como YouTube, se puede observar de manera evidente c\u00f3mo decisiones estrat\u00e9gicas relacionadas con el manejo de los agregados e invariantes pueden ejercer un impacto significativo en la eficiencia global del sistema. Dentro de este entorno, uno de los campos pre-calculados de mayor relevancia podr\u00eda ser, indudablemente, el contador de visualizaciones de los videos.<\/p>\n

Ante la abundancia de interacciones que suceden cada instante, mantener un conteo en tiempo real y preciso de las visualizaciones podr\u00eda resultar en un consumo considerable de recursos computacionales. En lugar de sostener un seguimiento detallado, YouTube podr\u00eda optar por actualizar este dato en bloques progresivos, como, por ejemplo, de 1000 en 1000 visualizaciones, tal como se puede inferir de la imagen.<\/p>\n

\"\"<\/p>\n

Este enfoque garantiza que el recuento de visualizaciones es no s\u00f3lo razonablemente exacto, sino, adem\u00e1s, eficiente en su mantenimiento.<\/p>\n

No obstante, si por razones particulares el negocio determinara que el numero debe reflejar la realidad con mayor rigidez (o sea, un n\u00famero exacto), ser\u00e1 necesario asumir el coste computacional que esto implique. Esto ilustra la importancia de las decisiones comerciales<\/strong> en el dise\u00f1o e implementaci\u00f3n de los sistemas y su impacto en el dise\u00f1o de software.<\/p>\n

Referencias de otras Entidades<\/h2>\n

Es importante destacar que un agregado no necesariamente tiene que comprender entidades completas. En numerosos casos, puede ser m\u00e1s eficiente y provechoso que un agregado mantenga simplemente una referencia a una entidad<\/strong> en lugar de la entidad en s\u00ed misma.<\/p>\n

Esta consideraci\u00f3n se torna especialmente relevante en contextos de alto desempe\u00f1o o en situaciones donde los recursos son limitados.<\/p>\n

En el agregado de un Pedido, es posible que no necesitemos la totalidad de la entidad del Usuario. En su lugar, podemos simplemente requerir su identificador \u00fanico (ID)<\/strong>.<\/p>\n

Este enfoque optimiza la utilizaci\u00f3n de la memoria y los recursos computacionales<\/strong>. En lugar de cargar todo el objeto de Usuario, que puede incluir una gran cantidad de atributos y relaciones, simplemente recuperamos y manejamos el identificador del Usuario, que es un valor ligero y manejable.<\/p>\n

Este planteamiento es un buen ejemplo de c\u00f3mo las decisiones de dise\u00f1o e implementaci\u00f3n pueden mejorar la eficiencia y la precisi\u00f3n del sistema<\/strong>, reforzando al mismo tiempo principios como el de la m\u00ednima exposici\u00f3n de datos.<\/p>\n

Un solo agregado por caso de uso<\/h2>\n

La creaci\u00f3n o modificaci\u00f3n de un agregado generalmente ocurre como resultado de la ejecuci\u00f3n de un caso de uso espec\u00edfico<\/strong>.<\/p>\n

Los cambios en el estado del sistema se realizan a trav\u00e9s de comportamientos bien definidos<\/strong> que se corresponden con casos de uso del mundo real.<\/p>\n

Por ejemplo, en el contexto de un sistema de comercio electr\u00f3nico, podr\u00edamos tener un caso de uso denominado \u00abCrear Pedido\u00bb. Este caso de uso estar\u00eda a cargo de recoger la informaci\u00f3n del usuario, los art\u00edculos que desea comprar y otros detalles pertinentes, para luego crear un nuevo agregado de Pedido y guardarlo en la base de datos.<\/p>\n

Los agregados son responsables de crear o modificar sus entidades<\/h2>\n

Un agregado es responsable de crear y modificar sus propias entidades<\/strong>. Esto se logra a trav\u00e9s de los llamados Factory Methods<\/strong>, que encapsulan la l\u00f3gica para la creaci\u00f3n y modificaci\u00f3n de entidades.<\/p>\n

Los m\u00e9todos de f\u00e1brica proporcionan una manera de asegurar que un agregado siempre est\u00e9 en un estado v\u00e1lido<\/strong>, ya que el propio agregado tiene el control total sobre c\u00f3mo y cu\u00e1ndo se crean o modifican sus entidades. Este patr\u00f3n promueve el encapsulamiento y fortalece la cohesi\u00f3n en el c\u00f3digo<\/strong>.<\/p>\n

Un ejemplo podr\u00eda ser la l\u00f3gica para a\u00f1adir un art\u00edculo a un pedido. En lugar de permitir que los clientes del c\u00f3digo creen directamente una entidad Articulo, el agregado Pedido podr\u00eda proporcionar un m\u00e9todo addArticle(params)<\/p>\n

Recomendaciones<\/h2>\n

Si desean profundizar a\u00fan m\u00e1s en este concepto y obtener una comprensi\u00f3n m\u00e1s completa de c\u00f3mo aplicarlo en sus proyectos, les recomiendo explorar los libros esenciales sobre Domain Driven Design. Dos de las obras m\u00e1s influyentes y autorizadas en el campo son conocidas com\u00fanmente como el ‘libro azul’ y el ‘libro rojo’ de DDD.<\/p>\n

El ‘libro azul’, titulado ‘Domain-Driven Design: Tackling Complexity in the Heart of Software’ escrito por Eric Evans, es una lectura obligatoria para cualquier persona interesada en DDD. Ofrece una visi\u00f3n profunda y detallada de la metodolog\u00eda, incluyendo el concepto de Agregados y muchos otros aspectos clave.<\/p>\n

\"\"<\/p>\n

Por otro lado, el ‘libro rojo’, llamado ‘Implementing Domain-Driven Design’ y escrito por Vaughn Vernon, proporciona una gu\u00eda pr\u00e1ctica sobre c\u00f3mo llevar a cabo DDD en proyectos del mundo real, lo que incluye una cobertura exhaustiva de los Agregados y su implementaci\u00f3n efectiva.<\/p>\n

\"\"<\/p>\n

Estos libros son recursos valiosos que te permitir\u00e1n profundizar en el mundo de DDD y perfeccionar tus habilidades en el dise\u00f1o de software centrado en el dominio<\/strong>. As\u00ed que, si deseas convertirte en expertos en Agregados y DDD, no dudes en explorar estas fuentes de conocimiento.<\/p>\n

En hiberus, somos especialistas en Domain-Driven Design y clean arquitecture<\/strong>. Dedicamos cada d\u00eda a mejorar y perfeccionar nuestro software. Nos respaldan a\u00f1os de experiencia y un constante aprendizaje, utilizando patrones arquitect\u00f3nicos reconocidos para garantizar la m\u00e1xima eficacia y desempe\u00f1o de nuestras soluciones.<\/p>\n

Creemos en un enfoque colaborativo y nos encantar\u00eda tener la oportunidad de trabajar junto a ti para potenciar tu sistema. Si sientes que podemos contribuir en tu organizaci\u00f3n, no dudes en contactarnos<\/a>. Estamos aqu\u00ed para ayudarte a alcanzar tus objetivos.<\/p>\n

\n
\n
\n
\n

\u00bfQuieres m\u00e1s informaci\u00f3n sobre nuestros servicios de agencia digital y tecnolog\u00eda para ecommerce?<\/p>\n

Contacta con nuestro equipo de hiberus digital<\/p>\n <\/div>\n

\n \n
\n

<\/p>

    <\/ul><\/div>\n
    \n
    \n<\/fieldset>\n
    \n\t
    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t\t

    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t

    <\/span>\n\t\t\t<\/p>\n\t\t<\/div>\n\t<\/div>\n\t

    \n\t\t
    \n\t\t\t