Blog Jose Cullar

Scrum Master, Solution Architect & Full Stack Developer

Domain-Driven Design. Modules & Aggregates

por Jose el 31 octubre, 2016

Modules

Los módulos son contenedores de elementos que nos permiten la organización de nuestro dominio. Denominados técnicamente como packages o namespaces. El objetivo principal es desacoplar y organizar los elementos dependiendo del contexto al que pertenecen. Siguiendo en todo momento el lenguaje obicuo.

Module naming conventions for the model and submodules

Normalmente y si la compañía dispone de un nombre de dominio en internet, el módulo principal empezará con com. Seguido del nombre de la organización.

El siguiente segmento de nombre de módulo identifica el Bounded Context local donde se aloja el módulo o contenedor de elementos.

No se recomienda utilizar los nombres comerciales de los productos de la organización en los nombres de módulos o submódulos ya que éstos pueden cambiar a lo largo del tiempo y en ocasiones no guarda relación directa con la responsabilidad del Bounded Context al que pertenece. Es preferible identificar el nombre de cada Bounded Context según su responsabilidad a elección del equipo. El objetivo es reflejar el lenguaje obicuo de la organización.

Los siguientes segmentos deben identificar en qué parte del sistema se encuentra. En sistemas con arquitecturas por capas sería recomendable utilizar los nombres específicos según cada capa.
more →

Domain-Driven Design. Services & Domain Events

por Jose el 6 octubre, 2016

Services

Podemos definir los servicios como procesos que realizan determinadas tareas. Empleados y evolucionados desde Service Oriented Architecture o Remote Procedure Call. Tareas o acciones genéricas que no se asocian a una única determinada única instancia de objeto, de modo que la tendencia más habitual es crear métodos estáticos sobre la entidad o agregado. Esta práctica no se considera óptima por no seguir los principios de desarrollo y dificultando en gran medida el testeo, además de considerarse mala práctica acceder a repositorios dentro de los agregados o entidades en el modelo de dominio. La necesidad de incluir métodos estáticos en el modelo de dominio es un buen indicador para crear un servicio.
more →

Domain-Driven Design. Entities & Value Objects

por Jose el 14 septiembre, 2016

Elementos más importantes para el modelado de dominio dentro del apartado táctico en el desarrollo orientado a DDD.

Entities

Definimos entidad como un concepto/objeto de dominio único (dispone de un identificador asociado). Los identificadores son únicos e inmutables, por ese motivo es aconsejable almacenar el identificador en un Value Object.

Comúnmente la tendencia de modelado de entidades refleja la estructura de datos, existiendo herramientas como los ORM generando un modelo de dominio totalmente mapeado a la estructura de datos mediante CRUD. Este método es muy útil para sencillas aplicaciones o sistemas con evolución limitada o nula. En cambio, no aconsejable para aquellas aplicaciones o sistemas que requieran una evolución y aumento progresivo en su complejidad. Siendo más aconsejable un modelado desacoplado a la estructura de datos, siendo más fiel a la lógica de dominio de la organización mediante lenguaje obicuo.
more →

Domain-Driven Design. Arquitectura

por Jose el 4 agosto, 2016

En este post introduciré estilos y patrones de arquitectura más interesantes y recomendables que puedes aplicar con DDD mencionados por Vaughn Vernon en “Implementing Domain-Driven Design”.

No se trata de una lista cerrada, ya que el enfoque táctico de Domain-Driven Design no requiere la utilización específica de ningún tipo de patrón o arquitectura: la verdadera importancia de cada Bounded Context reside en su Core Domain o modelo de dominio, independientemente de como se comunique con el resto de componentes de la aplicación, siempre y cuando se cumplan las buenas prácticas y los principios de calidad apropiados.
more →

Domain-Driven Design. Context Maps

por Jose el 27 julio, 2016

En el post anterior vimos los primeros pasos estratégicos y cómo disgregábamos la complejidad del negocio en Domains, Subdomains y Bounded Contexts.

Cada Bounded Context contiene o dispone de la tecnología, lenguaje de programación y arquitectura mínima necesaria para satisfacer los requerimientos de negocio de su contexto mediante un modelo de dominio. Las relaciones existentes entre Bounded Contexts se denominan Context Maps y las reglas necesarias para mapear/traducir un modelo de dominio de un determinado contexto a otro: Translation Map.

Una vez identificados los Bounded Contexts, deberemos establecer según necesidades de cada caso el tipo de relación entre ellos, marcando la dirección de flujo de información mediante Upstream (exposición de servicios) y Downstream (consumidor de servicios):


more →