Técnicas de Diseño - 2011

• Introducción• Motivación

o Algunos puntos claves: qué es? quién lo escribió? qué parte del software es la más compleja?

o Metodologías ágileso Lenguaje ubicuo

• Patrones propuestoso Aislar el dominio: arquitectura en capas.o Entityo Value Objecto Serviceso Repositorieso Factorieso Specification

• DDD o Domain Driven Design por Eric Evans en 2004.

• Objetivos:o Modelar el dominio siguiendo unos

principios básicos.o Hablar utilizando términos del dominio.o Dar un framework para los desarrolladores.

• La mayor complejidad del desarrollo se encuentra en el modelado del dominio.

• Considerar el modelado del dominio como algo no trivial.

• Estar interesado en el diseño orientado a objetos.

• Trabajar con iteraciones• Interacción directa entre desarrollador y

experto de dominio

• DDD no se lleva bien con metodologías no-agiles.

• Que todo el equipo use los mismos términos. Y que esos términos pertenezcan al dominio que se intenta modelar.

• Hablar con los expertos en el dominio y entender/usar los términos que ellos usan.

• No usar un doble lenguaje: uno con los expertos y otro en el equipo.

• El objetivo es reducir la complejidad al modelar un dominio.

• Utilizando patrones que aplican para el contexto en el que estamos. No usarlos como receta sino cuando aplican (no hay silver bullet).

• Si el dominio en sí mismo es complejo, no agregarle más complejidad! (p.ej: persistencia fuera del dominio).

• Aislar al dominio de la infraestructura.

• Utilizar arquitectura en capas para aislar al dominio de la infraestructura y permitir que distintos conceptos vayan en lugares separados.

• Concepto clave en DDD.

• Una entidad es un objeto que no está definido por sus atributos sino por su identidad. La identidad debe conservarse incluso cuando el objeto se persista o se transmita por algún medio. Deben poder ser identificadas de alguna forma.

• Determinar si un objeto es una entidad depende exclusivamente del modelo.

• Las entidades poseen un ciclo de vida y generalmente pasan por una serie de estados.

• Las entidades deben poseer un menanismo de identificación único: ej: id generado por db, id generado por usuario, uuid, etc.

• Sus operaciones equals/hashCode o similares se basan en su ID y no en sus atributos.

• Una entidad no debería poder construirse sin su id. La dejaría en un estado inválido.

• Ejemplos de entidad: Cliente, Cuenta Corriente, Usuario, etc.

• No todo es una entidad.

• Llevar rastro de entidades es costoso: tienen id único y ciclo de vida. Más difícil armar un modelo mental si todo es entidad.

• Un value object es un objeto que es definido solo por sus atributos. Dos value objects con los mismos atributos "son el mismo".

• Son objetos que describen cosas y no poseen identidad.

• Ejemplos?o Strings, Integer, Float. Nos importa que

instancia tenemos?

• No son solo "structs" con atributos, getters y setters. Deberían tener comportamiento.

• Foco en la inmutabilidad. Una vez construídos no cambiarán más.

• Son volátiles: los podemos "tirar" cuando no los necesitamos más.

• Que problemas se presentarían si tuviésemos un contexto así?

• A veces: ni entity ni value object.

• Operaciones que no corresponden a ningún objeto... dónde van? Forzarlas dejarían un objeto con muchas responsabilidades.

• Operaciones que involucran objetos del dominio pueden ser implementadas en un service... Pero no poner reglas de negocio en él, ellas van en los objetos.

• No terminar con objetos llamados "AlgoManager", nos indica que alguna regla se filtró.

• Los services no tienen estado. Actúan en base a los parámetros que reciben.

• Son llamados como actividad y no como sustantivo.

• El costo de entrega depende de la dirección de entrega, país, etc. Necesita conectarse con la empresa de entregas para saber el costo.

• Esconderlo en un service.

• Para poner el modelo a funcionar necesitamos un primer objeto, de dónde lo sacamos?

• Liberar al cliente de saber como recuperar instancias desde la persistencia. El repositorio encapsula los mecanismos.

• Que diferencias hay con el patrón DAO (Data Access Object)?

• El repositorio es parte del dominio, la implementación es parte de la infraestructura.

• Permite traer objetos que respondan a diversos criterios e incluso realizar cálculos.

• No resolver todo con repositorios, sino el modelo se volvería irrelevante.

• Se comporta como un set de objetos persistidos.

• Se usa en conjunto con el patrón Factory...

• Recupear un objeto de la db no es lo mismo que crear uno nuevo...

• Una posible arquitectura.

• Buscan atacar la complejidad: los objetos del dominio son complejos ya que tienen responsabilidades y deben mantener los invariantes (reglas de negocio). 

• Si les sumamos que se construyan ellos mismos... no es hacerlos más complejos?

• Extraer la complejidad en una fábrica.• Aliviar al cliente en el ensamblaje de los objetos.• Usar fábricas para construir objetos nuevos... y que

hacemos con los objetos persistidos?o Pueden haber violaciones a reglas de negocio.o Definir estrategias para superarlas.

Tiene como objetivo comunicar mejor las reglas de negocio de un dominio.

Encapsula un testeo lógico y responde a la pregunta: “esto valida?”

Puede usarse junto con repositorios para obtener una colección que valida un predicado.

Comunica con énfasis una regla importante para el dominio:

Una buena herramienta para usar ya que define una base de conceptos de los que se puede discutir.

El equipo debe estar comprometido para que se observen buenos resultados.

Se necesita implementar refactoring cuando se gana conocimiento del dominio.

Mauro Ciancio