Notas
1-Introducing Domain-Driving-Design
- A veces no hay consenso sobre cuál es el dominio más importante; cada departamento puede pensar que su dominio es el más importante. Y a veces, el dominio central es simplemente aquello en lo que su cliente quiere que trabajes.
- Ampliar la cadena eventos hasta donde se pueda permite detectar requisitos faltantes preguntando que evento precede a otro o cual sería el siguiente a otro.
- Caso de uso (DDD)
- Comando (DDD)
- Concéntrate en eventos y flujos de trabajo empresariales en lugar de estructuras de datos
- Context Map
- Divide el dominio del problema en subdominios más pequeños
- Dominios Core
- Dominios de soporte
- Dominios genéricos
- Escenario (DDD)
- Event Storming
- Evento de dominio
- Guía para identificar subdominios
- Guías para construir un modelo compartido entre personas que desarrolladoras y expertas de dominio
- Lenguaje Ubicuo
- Los subdominos son una parte pequeña de un dominio donde existe un conocimiento más especializado de este
- Modelo de dominio
- Primero hay que centrarse en entender el dominio antes de pensar en como implementar un modelo.
- Proceso de negocio
- Si quieres ser eficaz al desarrollar una solución, necesitas convertirte en un poco de experto en el dominio por ti mismo.
- Solo deberíamos capturar la información que sea relevante para resolver un problema particular. Todo lo demás es irrelevante.
- Un dominio en el espacio de problemas no siempre tiene una relación uno a uno con un contexto en el espacio de soluciones.
- Un dominio es un área del conocimiento asociada al problema que estamos tratando de resolver, o simplemente aquello en lo que un experto en dominio es experto.
- Workflow
2-Understanding The Domain
- Como desarrolladores, tendemos a centrarnos en cuestiones técnicas y a tratar todos los requisitos por igual. Las empresas no piensan así.
- Descubrir el dominio con el enfoque de definir los comandos y eventos que están involucrados en los workflows
- Documentación del dominio
- Persistence ignorance
3-A Functional Archirecture
- Arquitectura de software, enfoque C4
- Cada workflow se corresponderá a una función cuyo input es un objeto que representa un comando y su output es una lista de eventos.
- Capa anticorrupción
- Context Map 2
- Contruye tu solución inicialmente como un monolito y refactoriza a container desacoplados a medida que sea necesario
- El perímetro de un bounded context hace de frontera de confianza
- La comunicación entre bounded contexts tiene que ser mediante eventos
- los eventos y los DTOs relacionados forman una especie de contrato entre los contextos delimitados. Los dos contextos deberán acordar un formato común para ellos a fin de que la comunicación sea exitosa.
- Mantén los procesos IO en los bordes
- Un Bounded context en una arquitectura monolítica (un container C4), puede ser un modulo con una interfaz muy bien definida
- Un bounded context en una arquitectura orientada a servicios puede ser una unidad independientemente desplegable (container C4). Llevando esto al extremo con microservicios, cada workflow sería un container desplegable
- Un workflow no “publica” Eventos de Dominio , simplemente los devuelve. Cómo se publican es una preocupación aparte.
- Un workflow siempre está contenido dentro de un solo contexto delimitado y nunca implementa un escenario “de extremo a extremo” a través de múltiples contextos.
4-Understanding Types
5-Domain Modeling With Types
- Efectos (programación funcional)
- El agregado actúa como un límite de consistencia para garantizar que todos los datos dentro del agregado se actualicen correctamente al mismo tiempo
- Modelado de valores simples
- Modelar los types desconocidos
- Si un flujo de trabajo tiene diferentes entradas entre las que elegir (O), entonces podemos crear un tipo de elección. Pero si un proceso tiene varias entradas que son todas obligatorias (Y)
- Si un flujo de trabajo tiene una salida A o una salida B, entonces podemos crear un tipo de elección para almacenarlas ambas.
- Si un flujo de trabajo tiene una salida A y una salida B, entonces podemos crear un tipo de registro para almacenarlas ambas.
- Un agregado es la unidad atómica de persistencia, transacciones de bases de datos y transferencia de datos.
- Un agregado es una colección de objetos de dominio que pueden tratarse como una sola unidad, con la entidad de nivel superior actuando como «raíz»
6-Integrity and consistency
7-Modeling workflows as pipelines
- El comando debería contener todo lo necesario para que el workflow pueda procesar la petición. Además de metadatos que permitan hacer un tracking del mismo
- El input de un workflow debe ser siempre un objeto de dominio
- Gestiona estados creando un type que represente cada uno de estos
- Máquina de estados desde un perspectiva funcional
- Modela las dependencias como types de funciones
- Transformation oriented programming
- Usa genéricos para no repetir estructuras comunes entre comandos
- Usa un choice type para poder unificar una estructura de datos para varios comandos cuando solo hay un canal de comunicación de datos.