Factories

De todos los patrones tácticos usados en DDD, las factories son probablemente una de las mayormente conocidas y utilizadas. Encargadas de la creación de instancias de objetos que requieren cierta lógica de construcción que deseamos ocultar, siendo así un recurso que nos permite encapsular la complejidad de construcción de objetos. Conocidas como factory classes o factory methods.

Inicialmente la lógica de construcción de un objeto se realiza en el contructor. Cuando éste empieza a incrementar su complejidad mediante diversas lógicas, el objeto en sí no debe ser el responsable de controlarlas para crearse así mismo. Debemos extraerlas y encapsularlas en factories permitiéndonos asegurar una correcta instanciación de los objetos, evitando inconsistencias u objetos incorrectamente inicializados.

more →

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 →

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 →

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 →