SlideShare ist ein Scribd-Unternehmen logo
1 von 40
Downloaden Sie, um offline zu lesen
Webinar - Junio 2020 - v.01
DDD + HA + MS.
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.
Adaptabilidad.
Portabilidad.
Disponibilidad.
Continuidad.
Escalabilidad.
Observabilidad.
Mantenibilidad.
Reusabilidad.
Eficiencia.Verificabilidad.
Interoperabilidad.
Domain Driven Design.
01.
webinar Domain Driven Design & Hexagonal Architecture & Microservicios.
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.
Big picture.
Code architecture.
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.
Conceptos DDD - Big Picture.
01.01
Título presentación proyecto. Título sección.
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
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
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
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
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
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.
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
Conceptos DDD - Code Arch.
01.01
Título presentación proyecto. Título sección.
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
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
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
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
● 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.
Event Storming.
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.
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
Clean code Architectures.
02.
webinar Domain Driven Design & Hexagonal Architecture & Microservicios.
● 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.
Hexagonal Architecture.
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
Hexagonal Architecture & DDD.
Entities, Value objects, Aggregates,
FactoriesRepositories
Services
Onion Architecture.
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
Application
Domain Services
Domain
Test UI
Infrastructure
Onion Architecture & DDD.
Entities, Value objects, Aggregates,
Factories
Repositories
Services
Demo.
02.
webinar Domain Driven Design & Hexagonal Architecture & Microservicios.
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
Domain.
Dominio
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
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
¡Muchas
Gracias!.
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

Weitere ähnliche Inhalte

Was ist angesagt?

Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven DesignAndriy Buday
 
Domain Driven Design Quickly
Domain Driven Design QuicklyDomain Driven Design Quickly
Domain Driven Design QuicklyMariam Hakobyan
 
Design Patterns - General Introduction
Design Patterns - General IntroductionDesign Patterns - General Introduction
Design Patterns - General IntroductionAsma CHERIF
 
Domain Driven Design Introduction
Domain Driven Design IntroductionDomain Driven Design Introduction
Domain Driven Design Introductionwojtek_s
 
Clean architecture
Clean architectureClean architecture
Clean architecture.NET Crowd
 
Modelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven DesignModelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven DesignNaeem Sarfraz
 
How to Implement Domain Driven Design in Real Life SDLC
How to Implement Domain Driven Design  in Real Life SDLCHow to Implement Domain Driven Design  in Real Life SDLC
How to Implement Domain Driven Design in Real Life SDLCAbdul Karim
 
Domain driven design
Domain driven designDomain driven design
Domain driven designits_skm
 
DDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichDDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichIvan Paulovich
 
Introducing Clean Architecture
Introducing Clean ArchitectureIntroducing Clean Architecture
Introducing Clean ArchitectureRoc Boronat
 
Software architecture patterns
Software architecture patternsSoftware architecture patterns
Software architecture patternsMd. Sadhan Sarker
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean ArchitectureFlavius Stef
 
Domain Driven Design Demonstrated
Domain Driven Design Demonstrated Domain Driven Design Demonstrated
Domain Driven Design Demonstrated Alan Christensen
 
Refactoring for Domain Driven Design
Refactoring for Domain Driven DesignRefactoring for Domain Driven Design
Refactoring for Domain Driven DesignDavid Berliner
 
Deconstructing Monoliths with Domain Driven Design
Deconstructing Monoliths with Domain Driven DesignDeconstructing Monoliths with Domain Driven Design
Deconstructing Monoliths with Domain Driven DesignVMware Tanzu
 
DDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdfDDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdfEleonora Ciceri
 

Was ist angesagt? (20)

Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven Design
 
Domain Driven Design Quickly
Domain Driven Design QuicklyDomain Driven Design Quickly
Domain Driven Design Quickly
 
Design Patterns - General Introduction
Design Patterns - General IntroductionDesign Patterns - General Introduction
Design Patterns - General Introduction
 
Domain Driven Design Introduction
Domain Driven Design IntroductionDomain Driven Design Introduction
Domain Driven Design Introduction
 
Domain Driven Design
Domain Driven Design Domain Driven Design
Domain Driven Design
 
Clean architecture
Clean architectureClean architecture
Clean architecture
 
Modelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven DesignModelling a complex domain with Domain-Driven Design
Modelling a complex domain with Domain-Driven Design
 
How to Implement Domain Driven Design in Real Life SDLC
How to Implement Domain Driven Design  in Real Life SDLCHow to Implement Domain Driven Design  in Real Life SDLC
How to Implement Domain Driven Design in Real Life SDLC
 
Domain driven design
Domain driven designDomain driven design
Domain driven design
 
DDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan PaulovichDDD Tactical Design with Clean Architecture - Ivan Paulovich
DDD Tactical Design with Clean Architecture - Ivan Paulovich
 
Introducing Clean Architecture
Introducing Clean ArchitectureIntroducing Clean Architecture
Introducing Clean Architecture
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Software architecture patterns
Software architecture patternsSoftware architecture patterns
Software architecture patterns
 
Introduction to microservices
Introduction to microservicesIntroduction to microservices
Introduction to microservices
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
 
Domain Driven Design Demonstrated
Domain Driven Design Demonstrated Domain Driven Design Demonstrated
Domain Driven Design Demonstrated
 
Refactoring for Domain Driven Design
Refactoring for Domain Driven DesignRefactoring for Domain Driven Design
Refactoring for Domain Driven Design
 
Deconstructing Monoliths with Domain Driven Design
Deconstructing Monoliths with Domain Driven DesignDeconstructing Monoliths with Domain Driven Design
Deconstructing Monoliths with Domain Driven Design
 
Domain driven desing
Domain driven desingDomain driven desing
Domain driven desing
 
DDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdfDDD - 1 - A gentle introduction to Domain Driven Design.pdf
DDD - 1 - A gentle introduction to Domain Driven Design.pdf
 

Ähnlich wie Ddd + ah + microservicios

Meetup bdd & tdd: aprovecha_su_poder
Meetup bdd & tdd: aprovecha_su_poderMeetup bdd & tdd: aprovecha_su_poder
Meetup bdd & tdd: aprovecha_su_poderEduardo Riol
 
Meetup: Sesión #8 Domain Driven Design
Meetup: Sesión #8 Domain Driven DesignMeetup: Sesión #8 Domain Driven Design
Meetup: Sesión #8 Domain Driven DesignOsvaldo Mercado Coss
 
Arquitectura de software y otros demonios
Arquitectura de software y otros demoniosArquitectura de software y otros demonios
Arquitectura de software y otros demoniosAndrés Londoño
 
Personal informatico
Personal informaticoPersonal informatico
Personal informaticoHugo Teixido
 
Personalinformatico jaenes
Personalinformatico jaenesPersonalinformatico jaenes
Personalinformatico jaenesDavidJaenes
 
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptxM.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptxHawkMartnez
 
Business Logic 2012
Business Logic 2012Business Logic 2012
Business Logic 2012juanma_ari
 
Inyección de dependencias en Node.js con InversifyJS & TypeScript
Inyección de dependencias en Node.js con  InversifyJS & TypeScriptInyección de dependencias en Node.js con  InversifyJS & TypeScript
Inyección de dependencias en Node.js con InversifyJS & TypeScriptRemo Jansen
 
Visteme con 'Clean Architecture' que tengo prisas
Visteme con 'Clean Architecture' que tengo prisasVisteme con 'Clean Architecture' que tengo prisas
Visteme con 'Clean Architecture' que tengo prisasJosé María Pérez Ramos
 
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...Neo4j
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_softwareuniv of pamplona
 
Capitulo xiv expectativasparaunambientededesarrollo
Capitulo xiv expectativasparaunambientededesarrolloCapitulo xiv expectativasparaunambientededesarrollo
Capitulo xiv expectativasparaunambientededesarrolloarpamanpadopo
 
Zend Framework2
Zend Framework2Zend Framework2
Zend Framework2uni
 
VLCTechFest - Simplificando Controladores: Una introducción a Action-Domain ...
VLCTechFest -  Simplificando Controladores: Una introducción a Action-Domain ...VLCTechFest -  Simplificando Controladores: Una introducción a Action-Domain ...
VLCTechFest - Simplificando Controladores: Una introducción a Action-Domain ...Miguel Ángel Sánchez Chordi
 
Behavior1
Behavior1Behavior1
Behavior1arajar
 
Introducción a DDD
Introducción a DDDIntroducción a DDD
Introducción a DDDsergiopolo
 
Aspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareAspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareLenin Lozano
 

Ähnlich wie Ddd + ah + microservicios (20)

Domain driven design
Domain driven designDomain driven design
Domain driven design
 
Meetup bdd & tdd: aprovecha_su_poder
Meetup bdd & tdd: aprovecha_su_poderMeetup bdd & tdd: aprovecha_su_poder
Meetup bdd & tdd: aprovecha_su_poder
 
Meetup: Sesión #8 Domain Driven Design
Meetup: Sesión #8 Domain Driven DesignMeetup: Sesión #8 Domain Driven Design
Meetup: Sesión #8 Domain Driven Design
 
Arquitectura de software y otros demonios
Arquitectura de software y otros demoniosArquitectura de software y otros demonios
Arquitectura de software y otros demonios
 
Personal informatico
Personal informaticoPersonal informatico
Personal informatico
 
Personalinformatico jaenes
Personalinformatico jaenesPersonalinformatico jaenes
Personalinformatico jaenes
 
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptxM.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
M.G.E-y-R.L.E.A-Diseño-Arquitectonico.pptx
 
Renderizando la web del 2020
Renderizando la web del 2020Renderizando la web del 2020
Renderizando la web del 2020
 
Business Logic 2012
Business Logic 2012Business Logic 2012
Business Logic 2012
 
Inyección de dependencias en Node.js con InversifyJS & TypeScript
Inyección de dependencias en Node.js con  InversifyJS & TypeScriptInyección de dependencias en Node.js con  InversifyJS & TypeScript
Inyección de dependencias en Node.js con InversifyJS & TypeScript
 
Visteme con 'Clean Architecture' que tengo prisas
Visteme con 'Clean Architecture' que tengo prisasVisteme con 'Clean Architecture' que tengo prisas
Visteme con 'Clean Architecture' que tengo prisas
 
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
Operational Data Graph: Un enfoque innovador para optimizar las operaciones d...
 
2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software2. introduccion a la_ing_de_software
2. introduccion a la_ing_de_software
 
Capitulo xiv expectativasparaunambientededesarrollo
Capitulo xiv expectativasparaunambientededesarrolloCapitulo xiv expectativasparaunambientededesarrollo
Capitulo xiv expectativasparaunambientededesarrollo
 
Zend Framework2
Zend Framework2Zend Framework2
Zend Framework2
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
 
VLCTechFest - Simplificando Controladores: Una introducción a Action-Domain ...
VLCTechFest -  Simplificando Controladores: Una introducción a Action-Domain ...VLCTechFest -  Simplificando Controladores: Una introducción a Action-Domain ...
VLCTechFest - Simplificando Controladores: Una introducción a Action-Domain ...
 
Behavior1
Behavior1Behavior1
Behavior1
 
Introducción a DDD
Introducción a DDDIntroducción a DDD
Introducción a DDD
 
Aspect Oriented Programming Middleware
Aspect Oriented Programming MiddlewareAspect Oriented Programming Middleware
Aspect Oriented Programming Middleware
 

Mehr von Paradigma Digital

Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.
Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.
Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.Paradigma Digital
 
Java 8 time to join the future
Java 8  time to join the futureJava 8  time to join the future
Java 8 time to join the futureParadigma Digital
 
Programación Reactiva con Spring WebFlux
Programación Reactiva con Spring WebFluxProgramación Reactiva con Spring WebFlux
Programación Reactiva con Spring WebFluxParadigma Digital
 
Orquestando microservicios como lo hace Netflix
Orquestando microservicios como lo hace NetflixOrquestando microservicios como lo hace Netflix
Orquestando microservicios como lo hace NetflixParadigma Digital
 
Meetup microservicios: API Management
Meetup microservicios: API ManagementMeetup microservicios: API Management
Meetup microservicios: API ManagementParadigma Digital
 
Meetup de kubernetes, conceptos básicos.
Meetup  de kubernetes, conceptos básicos.Meetup  de kubernetes, conceptos básicos.
Meetup de kubernetes, conceptos básicos.Paradigma Digital
 
Docker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptx
Docker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptxDocker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptx
Docker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptxParadigma Digital
 
Implementando microservicios
Implementando microserviciosImplementando microservicios
Implementando microserviciosParadigma Digital
 
Equipo de Marketing de Paradigma Digital
Equipo de Marketing de Paradigma DigitalEquipo de Marketing de Paradigma Digital
Equipo de Marketing de Paradigma DigitalParadigma Digital
 
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!Paradigma Digital
 
Manuel Hurtado. Couchbase paradigma4oct
Manuel Hurtado. Couchbase paradigma4octManuel Hurtado. Couchbase paradigma4oct
Manuel Hurtado. Couchbase paradigma4octParadigma Digital
 
Programación Reactiva con RxJava
Programación Reactiva con RxJavaProgramación Reactiva con RxJava
Programación Reactiva con RxJavaParadigma Digital
 
¿Cómo vencer a los dragones digitales?
¿Cómo vencer a los dragones digitales?¿Cómo vencer a los dragones digitales?
¿Cómo vencer a los dragones digitales?Paradigma Digital
 

Mehr von Paradigma Digital (20)

Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.
Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.
Bots 3.0: Dejando atrás los bots conversacionales con Dialogflow.
 
Have you met Istio?
Have you met Istio?Have you met Istio?
Have you met Istio?
 
Linkerd a fondo
Linkerd a fondoLinkerd a fondo
Linkerd a fondo
 
Horneando apis
Horneando apisHorneando apis
Horneando apis
 
Java 8 time to join the future
Java 8  time to join the futureJava 8  time to join the future
Java 8 time to join the future
 
Programación Reactiva con Spring WebFlux
Programación Reactiva con Spring WebFluxProgramación Reactiva con Spring WebFlux
Programación Reactiva con Spring WebFlux
 
Orquestando microservicios como lo hace Netflix
Orquestando microservicios como lo hace NetflixOrquestando microservicios como lo hace Netflix
Orquestando microservicios como lo hace Netflix
 
Meetup microservicios: API Management
Meetup microservicios: API ManagementMeetup microservicios: API Management
Meetup microservicios: API Management
 
Meetup de kubernetes, conceptos básicos.
Meetup  de kubernetes, conceptos básicos.Meetup  de kubernetes, conceptos básicos.
Meetup de kubernetes, conceptos básicos.
 
Docker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptx
Docker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptxDocker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptx
Docker, kubernetes, openshift y openstack, para mi abuela. techfest 2017.pptx
 
Implementando microservicios
Implementando microserviciosImplementando microservicios
Implementando microservicios
 
Equipo de Marketing de Paradigma Digital
Equipo de Marketing de Paradigma DigitalEquipo de Marketing de Paradigma Digital
Equipo de Marketing de Paradigma Digital
 
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!
 
Overview atlas (1)
Overview atlas (1)Overview atlas (1)
Overview atlas (1)
 
Cómo usar google analytics
Cómo usar google analyticsCómo usar google analytics
Cómo usar google analytics
 
Transformación Digital
Transformación DigitalTransformación Digital
Transformación Digital
 
Manuel Hurtado. Couchbase paradigma4oct
Manuel Hurtado. Couchbase paradigma4octManuel Hurtado. Couchbase paradigma4oct
Manuel Hurtado. Couchbase paradigma4oct
 
Programación Reactiva con RxJava
Programación Reactiva con RxJavaProgramación Reactiva con RxJava
Programación Reactiva con RxJava
 
¿Cómo vencer a los dragones digitales?
¿Cómo vencer a los dragones digitales?¿Cómo vencer a los dragones digitales?
¿Cómo vencer a los dragones digitales?
 
Python y Flink
Python y FlinkPython y Flink
Python y Flink
 

Kürzlich hochgeladen

biometria hematica y hemostasia y preanalitica.pptx
biometria hematica y hemostasia y preanalitica.pptxbiometria hematica y hemostasia y preanalitica.pptx
biometria hematica y hemostasia y preanalitica.pptxmariabeatrizbermudez
 
Análisis del Modo y Efecto de Fallas AMEF.ppt
Análisis del Modo y Efecto de Fallas AMEF.pptAnálisis del Modo y Efecto de Fallas AMEF.ppt
Análisis del Modo y Efecto de Fallas AMEF.pptProduvisaCursos
 
CUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptx
CUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptxCUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptx
CUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptxfatimacamilainjantem
 
variables-estadisticas. Presentación powerpoint
variables-estadisticas. Presentación powerpointvariables-estadisticas. Presentación powerpoint
variables-estadisticas. Presentación powerpointaria66611782972
 
P.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptx
P.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptxP.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptx
P.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptxJafetColli
 
Los primeros 60 países por IDH en el año (2024).pdf
Los primeros 60 países por IDH en el año (2024).pdfLos primeros 60 países por IDH en el año (2024).pdf
Los primeros 60 países por IDH en el año (2024).pdfJC Díaz Herrera
 
REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024
REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024
REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024IrapuatoCmovamos
 
AMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docx
AMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docxAMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docx
AMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docxlm8322074
 
ROMA Y EL IMPERIO, CIUDADES ANTIGUA ROMANAS
ROMA Y EL  IMPERIO, CIUDADES  ANTIGUA ROMANASROMA Y EL  IMPERIO, CIUDADES  ANTIGUA ROMANAS
ROMA Y EL IMPERIO, CIUDADES ANTIGUA ROMANASanyahelmont
 
Letra de cambio definición y características.ppt
Letra de cambio definición y características.pptLetra de cambio definición y características.ppt
Letra de cambio definición y características.pptssuserbdc329
 
02 protocolo en caso de robo o asalto.pdf
02 protocolo en caso de robo o asalto.pdf02 protocolo en caso de robo o asalto.pdf
02 protocolo en caso de robo o asalto.pdfguillermobernalocamp1
 
Sistema Nacional de Vigilancia en Salud Pública SIVIGILA
Sistema Nacional de Vigilancia en Salud Pública SIVIGILASistema Nacional de Vigilancia en Salud Pública SIVIGILA
Sistema Nacional de Vigilancia en Salud Pública SIVIGILAsofiagomez288291
 
Porcentaje de población blanca europea en Europa Occidental (1923-2024).pdf
Porcentaje de población blanca europea en Europa Occidental (1923-2024).pdfPorcentaje de población blanca europea en Europa Occidental (1923-2024).pdf
Porcentaje de población blanca europea en Europa Occidental (1923-2024).pdfJC Díaz Herrera
 
MARCO TEORICO, SEMINARIO DE INVESTIGACION,
MARCO TEORICO, SEMINARIO DE INVESTIGACION,MARCO TEORICO, SEMINARIO DE INVESTIGACION,
MARCO TEORICO, SEMINARIO DE INVESTIGACION,EmmanuelDelJessGonza
 
EPIDEMIO CANCER PULMON resumen nnn.pptx
EPIDEMIO CANCER PULMON  resumen nnn.pptxEPIDEMIO CANCER PULMON  resumen nnn.pptx
EPIDEMIO CANCER PULMON resumen nnn.pptxJEFFERSONMEDRANOCHAV
 
Principales Retos Demográficos de Puerto Rico
Principales Retos Demográficos de Puerto RicoPrincipales Retos Demográficos de Puerto Rico
Principales Retos Demográficos de Puerto RicoRaúl Figueroa
 
Adultos Mayores más de 60 años como de la población total (2024).pdf
Adultos Mayores más de 60 años como  de la población total (2024).pdfAdultos Mayores más de 60 años como  de la población total (2024).pdf
Adultos Mayores más de 60 años como de la población total (2024).pdfJC Díaz Herrera
 
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombiadecreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombiaveronicayarpaz
 
INFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIAL
INFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIALINFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIAL
INFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIALMANUELVILELA7
 
max-weber-principales-aportes de la sociologia (2).pptx
max-weber-principales-aportes de la sociologia (2).pptxmax-weber-principales-aportes de la sociologia (2).pptx
max-weber-principales-aportes de la sociologia (2).pptxMarioKing10
 

Kürzlich hochgeladen (20)

biometria hematica y hemostasia y preanalitica.pptx
biometria hematica y hemostasia y preanalitica.pptxbiometria hematica y hemostasia y preanalitica.pptx
biometria hematica y hemostasia y preanalitica.pptx
 
Análisis del Modo y Efecto de Fallas AMEF.ppt
Análisis del Modo y Efecto de Fallas AMEF.pptAnálisis del Modo y Efecto de Fallas AMEF.ppt
Análisis del Modo y Efecto de Fallas AMEF.ppt
 
CUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptx
CUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptxCUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptx
CUADRO COMPARATIVO DE ARCHIVOS Y CARPETAS.pptx
 
variables-estadisticas. Presentación powerpoint
variables-estadisticas. Presentación powerpointvariables-estadisticas. Presentación powerpoint
variables-estadisticas. Presentación powerpoint
 
P.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptx
P.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptxP.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptx
P.P ANÁLISIS DE UN TEXTO BÍBLICO. TEMA 10.pptx
 
Los primeros 60 países por IDH en el año (2024).pdf
Los primeros 60 países por IDH en el año (2024).pdfLos primeros 60 países por IDH en el año (2024).pdf
Los primeros 60 países por IDH en el año (2024).pdf
 
REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024
REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024
REPORTE DE HOMICIDIO DOLOSO IRAPUATO ABRIL 2024
 
AMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docx
AMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docxAMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docx
AMNIOS Y CORDON UMBILICAL en el 3 embarazo (1).docx
 
ROMA Y EL IMPERIO, CIUDADES ANTIGUA ROMANAS
ROMA Y EL  IMPERIO, CIUDADES  ANTIGUA ROMANASROMA Y EL  IMPERIO, CIUDADES  ANTIGUA ROMANAS
ROMA Y EL IMPERIO, CIUDADES ANTIGUA ROMANAS
 
Letra de cambio definición y características.ppt
Letra de cambio definición y características.pptLetra de cambio definición y características.ppt
Letra de cambio definición y características.ppt
 
02 protocolo en caso de robo o asalto.pdf
02 protocolo en caso de robo o asalto.pdf02 protocolo en caso de robo o asalto.pdf
02 protocolo en caso de robo o asalto.pdf
 
Sistema Nacional de Vigilancia en Salud Pública SIVIGILA
Sistema Nacional de Vigilancia en Salud Pública SIVIGILASistema Nacional de Vigilancia en Salud Pública SIVIGILA
Sistema Nacional de Vigilancia en Salud Pública SIVIGILA
 
Porcentaje de población blanca europea en Europa Occidental (1923-2024).pdf
Porcentaje de población blanca europea en Europa Occidental (1923-2024).pdfPorcentaje de población blanca europea en Europa Occidental (1923-2024).pdf
Porcentaje de población blanca europea en Europa Occidental (1923-2024).pdf
 
MARCO TEORICO, SEMINARIO DE INVESTIGACION,
MARCO TEORICO, SEMINARIO DE INVESTIGACION,MARCO TEORICO, SEMINARIO DE INVESTIGACION,
MARCO TEORICO, SEMINARIO DE INVESTIGACION,
 
EPIDEMIO CANCER PULMON resumen nnn.pptx
EPIDEMIO CANCER PULMON  resumen nnn.pptxEPIDEMIO CANCER PULMON  resumen nnn.pptx
EPIDEMIO CANCER PULMON resumen nnn.pptx
 
Principales Retos Demográficos de Puerto Rico
Principales Retos Demográficos de Puerto RicoPrincipales Retos Demográficos de Puerto Rico
Principales Retos Demográficos de Puerto Rico
 
Adultos Mayores más de 60 años como de la población total (2024).pdf
Adultos Mayores más de 60 años como  de la población total (2024).pdfAdultos Mayores más de 60 años como  de la población total (2024).pdf
Adultos Mayores más de 60 años como de la población total (2024).pdf
 
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombiadecreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
decreto 2090 de 2003.pdf actividades de alto riesgo en Colombia
 
INFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIAL
INFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIALINFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIAL
INFORME FINAL ESTADISTICA DESCRIPTIVA E INFERENCIAL
 
max-weber-principales-aportes de la sociologia (2).pptx
max-weber-principales-aportes de la sociologia (2).pptxmax-weber-principales-aportes de la sociologia (2).pptx
max-weber-principales-aportes de la sociologia (2).pptx
 

Ddd + ah + microservicios

  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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
  • 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
  • 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