Notas
- 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.
- 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
- Comando (DDD)
- Concéntrate en eventos y flujos de trabajo empresariales en lugar de estructuras de datos
- Context Map 2
- Context Map
- Contruye tu solución inicialmente como un monolito y refactoriza a container desacoplados a medida que sea necesario
- Divide el dominio del problema en subdominios más pequeños
- Dominios Core
- Dominios genéricos
- El perímetro de un bounded context hace de frontera de confianza
- 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
- La comunicación entre bounded contexts tiene que ser mediante eventos
- Lenguaje Ubicuo
- 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.
- Los subdominos son una parte pequeña de un dominio donde existe un conocimiento más especializado de este
- Mantén los procesos IO en los bordes
- 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 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 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.
- 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.
- Workflow