El objetivo de la presentación es ayudar con trucos y consideraciones para mover nuestras aplicaciones del nivel 3 al nivel 4 de una forma práctica y reduciendo los costes de transición (de menor coste/complejidad a mayor sin comprometer mucho el siguiente paso). Veremos cómo desacoplar sin eventos de dominio sobre el mismo monolito, algunos trucos para mejorar la asincronía, cómo usar eventos con un monolito, la diferencia entre orquestrar y coordinar, y mucho más!

1. EVENTOS, MENSAJERÍA
Y OTRAS FÁBULAS
CARLOS @BUENOSVINOS - #PULPOCON19

2. @BUENOSVINOS

4. Domain-Driven
Design in PHP
Carlos Buenosvinos, Christian Soronellas and Keyvan Akbary
https://leanpub.com/ddd-in-php

6. INTENTO AYUDAR A MEJORAR
TÉCNICAMENTE CON CAMBIOS PEQUEÑOS,
BARATOS, PROGRESIVOS Y RÁPIDOS

8. BASADO EN MIS CLIENTES
BUENOSVINOS MATURITY MODEL
▸ Level 1: Spaguetti
▸ Level 2: Framework Fanboy
▸ Level 3: Hexagonal Architecture
▸ Level 4: Hexagonal + Domain Events
▸ Level 5: Stepping Store (CQRS w/o ES)
▸ Level 6: CQRS + Event Sourcing

9. OBJETIVO
OBJETIVO DE LA CHARLA
▸ Ayudaros con trucos y consideraciones para
mover nuestras aplicaciones del nivel 3 al nivel
4 de una forma práctica y reduciendo los
costes de transición (de menor coste/
complejidad a mayor sin comprometer mucho
el siguiente paso).
▸ Level 3: Hexagonal Architecture
▸ Level 4: Hexagonal + Domain Events

10. NIVEL 3: HEXAGONAL

13. MATERIAL EN VIDEOS
REFACTORIZAR HACIA HEXAGONAL
▸ https://carlosbuenosvinos.com/rigor-talks-php-13-refactor-use-case-i-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-14-refactor-use-case-ii-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-15-refactor-use-case-iii-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-16-refactor-use-case-iv-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-17-refactor-use-case-v-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-18-tell-dont-ask-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-19-refactor-use-case-vi-spanish/

14. DE NIVEL 3 A 4
(HEX + EVENTOS)

15. “A DOMAIN EVENT IS A
RECORD OF SOME
BUSINESS-SIGNIFICANT
OCCURRENCE IN A
BOUNDED CONTEXT”
Vaughn Vernon

16. MATERIAL EN VIDEOS
EVENTOS DE DOMINIO
▸ https://carlosbuenosvinos.com/rigor-talks-php-22-domain-events-i-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-23-domain-events-ii-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-24-domain-events-iii-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-25-persisting-domain-events-spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-26-distributing-domain-events-using-rest-
spanish/
▸ https://carlosbuenosvinos.com/rigor-talks-php-27-distributing-domain-events-using-rabbitmq-
spanish/

17. LOS BENEFICIOS DE LOS EVENTOS DE DOMINIO
SON: MEJORAN EL DESACOMPLAMIENTO Y
MEJORAN EL RENDIMIENTO (USÁNDOSE DE
FORMA ASINCRONÍA)

18. DESACOPLAMIENTO Y
ASINCRONÍA…

19. Y SI NO ESTUVIERAMOS LISTOS
PARA EVENTOS/MENSAJERÍA
(TODAVÍA)…

20. PODEMOS OBTENER LOS MISMOS
BENEFICIOS SIN USAR EVENTOS DE
DOMINIO?

21. IF (MONOLITO)

22. NO ESTAMOS LISTOS (Y ADEMÁS TENGO UN MONOLITO)
MEJORAR DESACOPLAMIENTO (PERO NO ASINCRONÍA)
▸ /src
▸ /User
▸ /Billing
▸ /Inventory
▸ Prohibir la instanciación (new MyClass) entre carpetas de
cada Bounded Context (Billing vs. Inventory, por ejemplo) y
usar llamadas API REST entre cada Bounded Context
▸ Git precommit Hook + Check Style
▸ Autoload Composer (@dev)
▸ Runtime con Factory (Caller Stack simulando friend
visibility)

23. NO ESTAMOS LISTOS (Y ADEMÁS TENGO UN MONOLITO)
MEJORAR DESACOPLAMIENTO (PERO NO ASINCRONÍA)
MI MONOLITO
(DESDE BILLING)
MI MONOLITO
200
/users/…

24. NO ESTAMOS LISTOS (Y ADEMÁS TENGO UN MONOLITO)
MEJORAR ASINCRONÍA (LLAMADAS QUE NO REQUIEREN RESPUESTA)
MI MONOLITO
(DESDE BILLING)
MI MONOLITO
201
/users/…

25. NO ESTAMOS LISTOS (Y ADEMÁS TENGO UN MONOLITO)
OPCIONES EN EL LADO SERVIDOR
C. Background Job (BD, REDIS, RabbitMQ)
A. fastcgi_finish_request
MI MONOLITO B. cron

26. NO ESTAMOS LISTOS (Y ADEMÁS TENGO UN MONOLITO)
MEJORAR ASINCRONÍA (LLAMADAS QUE REQUIEREN RESPUESTA / POOLING)
MI MONOLITO
(DESDE BILLING)
MI MONOLITO
201 (+ ?pool_url)
/users/…
pool_url

27. NO ESTAMOS LISTOS (Y ADEMÁS TENGO UN MONOLITO)
MEJORAR ASINCRONÍA (LLAMADAS QUE REQUIEREN RESPUESTA / PUSH WEBHOOK)
MI MONOLITO
(DESDE BILLING)
MI MONOLITO
201
webhook_url
/users/… (+ webhook_url)

28. IF (SERVICES)

29. NO ESTOY LISTA PARA EVENTOS (Y ADEMÁS TENGO SERVICIOS)
IGUAL QUE CON MONOLITO PERO HAY 2 O MÁS SERVICIOS
SERVICIO 1 SERVICIO 2
201
201 (+ webhook_url)
webhook_url

30. https://www.youtube.com/watch?v=kBlmEfljrn0

31. Y SI ESTUVIÉRAMOS LISTOS
PARA EVENTOS/MENSAJERÍA…

32. BÁSICOS

34. BÁSICOS
DISPARANDO EVENTOS (ESTÁTICAMENTE)

35. DISPARANDO EVENTOS (DESDE LA ENTIDAD)

36. SI NO TENÉIS SYMFONY O SIMILAR, NO PASA NADA…
Domain Event
Publisher
Example

37. TRUCOS

38. PERSISTIR TODOS LOS EVENTOS EN BBDD
Domain Event
Listener
(MySQL Example)

39. PUBLICAR API REST CON LOS EVENTOS

40. MESSAGE IDS

41. MESSAGE IDS
MESSAGE ID, CAUSATION ID & CORRELATION ID

42. MESSAGE IDS
MESSAGE ID, CAUSATION ID & CORRELATION ID

43. MESSAGE IDS
MESSAGE ID, CAUSATION ID & CORRELATION ID

44. META INFO

45. META INFO
META DATOS INTERESANTES
▸ webhooks_endpoint_url
▸ De la misma forma que con HATEOAS en
APIs REST
▸ documentation_url
▸ Para la mejora de Experiencia de
Developer
▸ deprecated
▸ Campos deprecados o consideraciones a
tener en cuenta

46. VERSIONADO

47. VERSIONADO
MUCHAS DIFICULTADES…
▸ Eventos ya enviados
▸ Retrocompatibilidad para Consumers viejos
▸ Replay de eventos viejos con código nuevo
▸ …

49. VERSIONADO
ALGUNAS CONSIDERACIONES PARA EVITAR PARTE DEL DOLOR
▸ Sólo agrega campos nuevos al Evento (a los consumers viejos no le importará)
▸ user.birthday en ISO 8601 y agregamos user.birthday_in_timestamp
▸ No eliminamos campos del Evento (podemos marcarlos como deprecated en
la información meta)
▸ No modificamos contenido de Eventos ni formatos (agregamos campo nuevo)

50. CHOREOGRAPHED VS.
ORCHESTRATED

51. CHOREOGRAPHED VS. ORCHESTRATED
EJEMPLO: RESTAURANTE ASÍNCRONO (REQUERIMIENTO INICIAL)
WAITER COOK
ASSISTANT MANAGERCASHIER
1. Toma el pedido 2. Cocina el pedido
3. Calcula $4. Cobra el pedido

52. CHOREOGRAPHED VS. ORCHESTRATED
COMUNICACIÓN: EVENT IN, EVENT OUT
WAITER COOK
ASSISTANT MANAGERCASHIER
OrderPlaced
OrderCooked
OrderAccountedOrderCashed

53. CHOREOGRAPHED VS. ORCHESTRATED
COMUNICACIÓN: COMMAND IN, COMMAND OUT
WAITER COOK
ASSISTANT MANAGERCASHIER
CookOrder
AccountOrder
CashOrder

54. FEATURE NUEVO: EL
CLIENTE PAGA PRIMERO…

55. CHOREOGRAPHED VS. ORCHESTRATED
DIFÍCIL IMPLEMENTAR EL FLUJO CON EVENT IN/EVENT OUT
WAITER COOK
ASSISTANT MANAGERCASHIER
OrderPlaced
OrderCooked
OrderAccountedOrderCashed

56. CHOREOGRAPHED VS. ORCHESTRATED
SOLUCIÓN: PROCESS MANAGER (EVENT IN, COMMAND OUT)
WAITER COOK
ASSISTANT MANAGERCASHIER
ORCHESTRATOR
(PROCESS MANAGER)
OrderPlaced
CookOrder
OrderCooked
order.userPaysFirst: True / False
Múltiples flujos
o diferentes PM

57. CHAOS MESSAGING
DEVELOPMENT

58. FORCEMOS EN DESARROLLO LO QUE PUEDE
OCURRIR EN PRODUCCIÓN (PÉRDIDA DE
MENSAJES Y DUPLICIDAD DE MENSAJES)

59. CHAOS MESSAGING DEVELOPMENT
CUSTOM TRANSPORTER FOR DUPLICATING MESSAGES (EXAMPLE IN SYMFONY)

60. CHAOS MESSAGING DEVELOPMENT
CUSTOM TRANSPORTER FOR DROPPING MESSAGES (EXAMPLE IN SYMFONY)

61. CHAOS MESSAGING DEVELOPMENT
SI DUPLICÁIS UN 20% DE MENSAJES Y PERDÉIS UN 20% DE MENSAJES (CUALQUIER RED SERÁ MEJOR)
SERVICIO A SERVICIO B
20% DROPPED MESSAGES
20% DUPLICATED MESSAGES

62. BATALLANDO CON
DUPLICIDAD Y PÉRDIDAS

63. BATALLANDO CON DUPLICIDAD Y PÉRDIDAS
QUÉ PASA SI SE DUPLICARAN (20% DE COOKORDER) MENSAJES?
WAITER COOK
ASSISTANT MANAGERCASHIER
ORCHESTRATOR
(PROCESS MANAGER)
OrderPlaced
CookOrder
OrderCooked
CashOrder

64. CHOREOGRAPHED VS. ORCHESTRATED
PROBLEMA: COOK RECIBE COOKORDER DUPLICADOS
COOKORCHESTRATOR
(PROCESS MANAGER)
CookOrder
SOLUCIÓN #1: CONTROL DE IDS VISTOS EN COOK
SOLUCIÓN #2: COOKORDER ES IDEMPOTENTE (ORDER IS COOKED?)
CookOrder
CookOrder
OrderCooked

65. BATALLANDO CON DUPLICIDAD Y PÉRDIDAS
QUÉ PASA SI SE PERDIERAN (20% DE COOKORDER) MENSAJES?
WAITER COOK
ASSISTANT MANAGERCASHIER
ORCHESTRATOR
(PROCESS MANAGER)
OrderPlaced
CookOrder
OrderCooked
CashOrder

66. CHOREOGRAPHED VS. ORCHESTRATED
PROBLEMA: COOK NO RECIBE COOKORDER
COOKORCHESTRATOR
(PROCESS MANAGER)
SOLUCIÓN #1: TIMEOUT EN N SEGUNDOS Y REPUBLICAR
CRON / REDIS LOCAL / NO USANDO PHP
CookOrderTimeout

67. BATALLANDO CON DUPLICIDAD Y PÉRDIDAS
WAITER COOK
ASSISTANT MANAGERCASHIER
ORCHESTRATOR
(PROCESS MANAGER)
OrderPlaced
CookOrder
OrderCooked
CashOrder

68. CONCLUSIONES
RESUMEN
▸ Antes de usar Eventos y Mensajería podemos:
▸ Separar los BC en Módulos con restricciones de
instanciación y usando REST contra la misma app.
Usar fastcgi_finish_request, crons o background
tasks. Webhooks
▸ Evitar lo máximo los problemas de versionado de
Eventos añadiendo campos (sin eliminar ni modificar
existentes)
▸ Usar Correlation Id, Causation Id además del Message
Id para mejorar la observability
▸ Meter META INFO en los Eventos como Documentación

69. CONCLUSIONES
RESUMEN (II)
▸ Coreografía vs. Orchestración
▸ Chaos Messaging
▸ Idempotencia y control de Ids para Duplicación
▸ TimeOut para pérdida de paquetes

70. GRACIAS A TOD@S!
(MENUDA CHAPA / FUMADA)
@BUENOSVINOS