La arquitectura de microservicios persigue maximizar la adaptabilidad de las soluciones mediante la distribución de las responsabilidades del software en servicios con ciclo de vida independiente. Lograr la independencia de los microservicios es clave para beneficiarse de las ventajas de la arquitectura. Esto exige un profundo entendimiento del dominio funcional, lo que se logra mediante DDD. Por otro lado la arquitectura hexagonal nos permite estructurar el software de manera que la capa de código relacionada con el dominio funcional no se vea interferida por aspectos tecnológicos, es decir, que dicha capa sólo exprese el Ubiquitous Language, es decir el lenguaje del modelo en según lo llama DDD. Dicha separación en capas y el invertir las dependencias permite además garantizar la máxima portabilidad del código. ¿Qué vamos a ver? 1. Beneficios 2. Domain Driven Design. - Conceptos - Big Picture. - Conceptos - Code architecture. - Event Storming. 3. Clean Code Architecture. - Hexagonal Architecture. - Onion Architecture.

1. Webinar - Junio 2020 - v.01
DDD + HA + MS.

2. Qué
vamos
a ver.
1. Beneficios
2. Domain Driven Design.
○ Conceptos - Big Picture.
○ Conceptos - Code architecture.
○ Event Storming.
3. Clean Code Architecture.
○ Hexagonal Architecture.
○ Onion Architecture.
4. Demo.
5. Preguntas y … alguna respuesta.

3. Adaptabilidad.
Portabilidad.
Disponibilidad.
Continuidad.
Escalabilidad.
Observabilidad.
Mantenibilidad.
Reusabilidad.
Eficiencia.Verificabilidad.
Interoperabilidad.

4. Domain Driven Design.
01.
webinar Domain Driven Design & Hexagonal Architecture & Microservicios.

5. Domain Driven Design.
Es una aproximación holística al diseño de software
que va más allá de los aspectos técnicos, centrándose
en aspectos culturales y organizacionales de una
empresa que busca entregar valor.

6. Big picture.

7. Code architecture.

8. Strategic Design.
Problem Space Solution Space
¿Qué? ¿Cómo?
Separar, durante el análisis, el espacio del problema, del espacio
de la solución es necesario para un correcto entendimiento del
problema y por lo tanto un mejor diseño de la solución.
Cuanto más solapamiento haya entre la solución y el problema,
mejor y en esto se centra DDD:
● Persigue que los expertos de negocio y los técnicos
trabajen juntos en entender el dominio (Domain), es
decir el problema.
● Busca la separación del dominio, de los aspectos
tecnológicos, lo que permite una mejor comprensión del
dominio.
● Aporta herramientas para dividir el dominio en parcelas
más pequeñas, lo que lleva a soluciones modulares.

9. Conceptos DDD - Big Picture.
01.01
Título presentación proyecto. Título sección.

10. Domain.
Problem Space Solution Space
¿Qué?
¿Cómo?
El dominio o Domain es, en términos de DDD, el problema de
negocio para el que se está diseñando la solución.
El primer ejercicio que propone DDD es entender, de la mano de
los expertos el Domain, el problema de negocio.
Para ello se pueden realizar dinámicas inclusivas como Event
Storming. Lo que es importante durante las mismas es que se
hable en exclusiva del problema, sin referirlo a la tecnología, a
la solución.
El Domain trata de el todo, es decir de todos los procesos de la
empresa (Big Picture) y está formado por subdominios.
Domain

11. Ubiquitous Language.
CASA
HOGAR
ÁRBOL
CAMINO
Host
ShadowGenerator
Bus
¿Cómo lo ve negocio? ¿Cómo lo ve IT?
El lenguaje es regulador del pensamiento
-- Vygotsky

12. Ubiquitous Language.
¿Cómo lo ve Mantenimiento?
● Contador
● Modelo ….
● Cuándo fue la última
revisión?
● Cuando es más optima la
siguiente revisión?
● …
● ...
¿Cómo lo ve Comercial?
● Tipo de cliente
● Posible upselling
● Tiene bien ajustada la
potencia contratada?
● Qué tipo de vivienda según
su consumo
El lenguaje es regulador del pensamiento
-- Vygotsky

13. Ubiquitous Language.
● Es el lenguaje consensuado y empleado
por los expertos de negocio para definir y
tratar un subdominio concreto.
● Distintos Ubiquitous Languages siginifica
distintos subdominios.
● IT debe alinearse con el Ubiquitous
Language de su subdominio.
● Evoluciona a medida que evoluciona el
conocimiento sobre el modelo y el propio
modelo.
El código debe explicitar el Ubiquitous Language
Problem Space Solution Space
¿Qué?
¿Cómo?Domain
Ubiquitous
Language

14. Bounded Context.
El Bounded Context es la herramienta básica
para dividir el Domain en subdomains.
Se identifican en base al Ubiquitous
Language, pues son las fronteras que al ser
cruzadas cambia el entendimiento de los
conceptos.
Problem Space Solution Space
¿Qué? ¿Cómo?
Domain Bounded Context
Ubiquitous
Language

15. Bounded Context - Beneficios.
Comercial
Producción
People
Dividir el Domain en Subdomains mediante
Bounded Context:
● Mejora la especialización de los equipos y
el alineamiento entre el negocio e IT
● La división del problema lleva a una
solución con más cohesión y reduce la
dependencia entre equipos.
● Como hay un desacoplamiento fuerte
entre los subdominios, pueden ser
desarrollados con tecnologías distintas.

16. Context Mapping.
Comercial
Producción
People
● Los subdominios no están aislados, tienen
dependencias entre ellos.
● Las dependencias impactan en la
capacidad de evolución de cada uno.
● Context Mapping es la herramienta para
diagramar y especificar las distintas
relaciones entre los subdomain.
● Es la pieza clave para entender cómo cada
subdominio debe “protegerse” de la
dependencia que tiene con el resto en
base al patrón que ésta representa.
Shared Kernel
Open hostConformist

17. Conceptos DDD - Code Arch.
01.01
Título presentación proyecto. Título sección.

18. Comercial
Entity
Concepto que tiene identidad propia, de modo que
aunque tenga los mismo valores en sus atributos
que otro, no serán el mismo objeto.
Value Object
Son conceptos que no tienen identidad propia,
son anotaciones, valores. Si sus atributos tienen
el mismo valor que otro Value Object, entonces se
trata del mismo objeto. Son inmutables y así hay
que implementarlos
Cliente
RFP
FechaDirección
Entities & Value Objects.
Value
Object
EntityValueObject_A + 1 !== ValueObject_A + 1 -> ValueObject_B
ID
ID

19. Comercial
● Son pieza clave en el diseño DDD.
● Se encargan de almacenar y trasaccionar
el estado del sistema.
● Los simples (una sola Entity) o complejos
(varias Entities con root)
Cliente
<<root>>
RFP
FechaDirección
Aggregates.
ANS
Aggregate
ID
ID
ID
Value
Object
Entity

20. Comercial
Cliente
<<root>>
RFP
FechaDirección
Repositories & Factories.
ANS
ID
ID
ID
Repositories
Son los encargados de persistir y recuperar el
estado de los Aggregates.
Factories
Son las encargadas de la creación de las
entidades. Sirven de encapsulación.
RepositoryFactory
ClienteFactory
RFPFactory
ClienteRepository
RFPRepository
Aggregate
Value
Object
Entity

21. Comercial
Cliente
<<root>>
RFP
FechaDirección
Events & Commands & Services.
ANS
ID
ID
ID
Commands
● Son acciones inmutables que desencadenan un cambio en
uno o varios Aggregates.
● Siempre se escriben en infinitivo
● Normalmente se envían mediante mecanismos sincronos
(RPC) o asíncronos (API REST)
Events
● Son hechos inmutables que publican los Aggregates
cuando modifican su estado.
● Son imprescindibles para la coreografía de los Aggregates.
● Siempre se escriben en pasado.
● Normalmente se persisten en un Event Hub.
Services
Son los encargados de implementar el comportamiento que el
Domain prescribe como consecuencia de un Command.
ClienteFactory
RFPFactory
ClienteRepository
RFPRepository
EventCommand
Enviar RFP
RFP Enviado
RepositoryFactory
Aggregate
Value
Object
Entity

22. ● No permitir que una transacción afecten a más
de un Aggregate (huir de 2PC o SAGAS)
● Asumir consistencia eventual entre distintos
Aggregates.
● Huir de los getter y setters, el código debe
explicitar el Domain.
● Un microservicio podrá ser de grande como un
Bounded Context y nunca más pequeño que un
Aggregate.
● Lo Aggregates referencian a otros Aggregates
por su ID, nunca lo encapsulan.
● Escribir el código de manera que la expresión
de Domain no esté manchada de accidentes
tecnológicos.
Buenas prácticas.

23. Event Storming.

24. Event Storming.
● Dinámica de grupos que persigue conceptualizar un
Domain juntando a expertos de dominio con expertos de
IT.
● Es un proceso iterativo y colaborativo, que busca alinear
conceptos y trabajar el Ubiquitous Language.
● Define el proceso o Domain desde el punto de vista de
su comunicación, al revés que BPMN que lo define desde
el punto de vista de los estados.
● Creada por Alberto Brandolini.

25. Event Storming - ¿Cómo se hace?
● Buscar una gran pared en la que poner un papel de rollo que servirá como
soporte.
● Involucrar a expertos del negocio y el equipo de IT que va a desarrollar la
solución tecnológica -> Todos deben empaparse de Ubiquitous Language.
● Es importante que el moderador sitúe la conversación siempre en el espacio
del problema. Estamos definiendo el Domain, el problema de negocio.
● Respetar el código de colores de los post-its:
○ Naranja: Eventos
○ Azul: Comandos
○ Rosa: Comandos externos
○ Amarillo: Aggregates
○ Amarillo: Usuario
○ Verde: Vista del usuario
○ Morado: Política de negocio.
1. Se empieza siempre colocando eventos (escritos en pasado) sin orden temporal (divergencia)
2. Se coloca el origen de cada evento(convergencia)
3. Se revisa de cronología de eventos (convergencia)
4. Se revisan de políticas de negocio (convergencia) y la transaccionalidad
5. Se revisan los eventos de fallo
6. Se repite el proceso
Proceso

26. Clean code Architectures.
02.
webinar Domain Driven Design & Hexagonal Architecture & Microservicios.

27. ● Dependencia estricta: La clase A usa la clase B
para realizar una operación. La clase B está
hardcodeada en A.
● Inyección de dependencia: La clase A espera
que le sea pasado en tiempo de ejecución un
objeto B para realizar la operación.
Dependency Injection & Interfaces.
● Las interfaces nos permiten especificar un
comportamiento esperado. Nos permiten
explicitar el Domain.
● Mediante la inyección de dependencia de
interfaces podemos especificar el
comportamiento esperado de los objetos
inyectados.

28. Hexagonal Architecture.

29. Hexagonal Architecture.
● Arquitectura que busca la separación completa
del código de negocio (Domain) de los
accidentes tecnológicos.
● Emplear Adapters/ports para la interacción
con agentes externos al Domain (bdd, colas,
APIs, etc)
● Son los adapters o puertos los que instancian
el Domain (inversión de dependencias), no al
revés.
● Código de negocio no se mancha con
accidentes tecnológicos, sólo expresa el
Domain.
● Se maximiza la portabilidad de las
aplicaciones porque queda completamente
aislada la capa de infraestructura.
● Mismo código de Domain (Domain Model)
cuando se porta el software.
Beneficios

30. Hexagonal Architecture & DDD.
Entities, Value objects, Aggregates,
FactoriesRepositories
Services

31. Onion Architecture.

32. Application
Domain Services
Onion Architecture.
● Arquitectura que busca la separación completa del
código de negocio (Domain) de los accidentes
tecnológicos.
● Diferencia claramente la capa de aplicación de las capas
de dominio, de presentación e infraestructura.
● Exige que se pueda ejecutar la aplicación sin la capa de
infraestructura.
● Las capas de fuera instancian a las de dentro.
● Las de dentro publican interfaces que implentan las de
fuera.
● Código de negocio no se mancha con accidentes
tecnológicos, sólo expresa el Domain.
● Se maximiza la portabilidad de las aplicaciones
porque queda completamente aislada la capa de
infraestructura.
● Mismo código de Domain (Domain Model) cuando
se porta el software.
Beneficios
Domain
Test UI
Infrastructure

33. Application
Domain Services
Domain
Test UI
Infrastructure
Onion Architecture & DDD.
Entities, Value objects, Aggregates,
Factories
Repositories
Services

34. Demo.
02.
webinar Domain Driven Design & Hexagonal Architecture & Microservicios.

35. Qué vamos a ver?.
● Un desarrollo en Python diseñado desde el prisma
Domain Driven Design y estructurado mediante Onion
architecture.
● Vamos a probar la portabilidad del Domain Model: No se
ve afectado a pesar de que lo vamos a ejecutar en un
modo Mono proceso y en modo Multiproceso.
● Funcionalmente es pequeño: Un cerebro de un
autómata que ejecuta tareas.
● En función del resultado de las acciones, mejora o
empeora su estado de humor.
Monoproceso-multihilo.
● Los hilos se comunican entre sí mediante
colas fifo en memoria.
● Toda la persistencia es en memoria
Multiproceso-monohilo.
● Los procesos se comunican entre sí mediante
colas AWS SQS fifo.
● La persistencia es en Dynamodb y memoria

36. Domain.
Dominio

37. Logger, Idefier,
Estado Humor,
Acciones
eventos,
comandos, tareas
Domain en modo MONO proceso.
aiohttp
POST /accion
GET /acciones
POST /task
Hilos
Aplicación
Infraestructura
Dominio

38. Logger, Idefier,
Estado Humor
eventos,
comandos, tareas
Domain en modo MULTI proceso.
Flask
POST /accion
GET /acciones
POST /task
Acciones
Dominio
Aplicación
Infraestructura
Procesos

39. ¡Muchas
Gracias!.

40. Referencias.
● Libro: Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans
● Libro: Implementing Domain-Driven Design, Vaughn Vernon
● Canal de Youtube de Vaughn Vernon
● Ejemplo del webinar: https://github.com/jpardobl/jpardobl-trastobrain
● Python DDD Example: https://github.com/Ermlab/python-ddd
● Demo en Java: https://github.com/citerus/dddsample-core
● Event Storming https://developer.ibm.com/technologies/java/tutorials/reactive-in-practice-1/
Javier Pardo Blasco jpardo@paradigmadigital.com