Introducción al Domain Driven Design para el Meetup de Queretaro Software Development

1. Querétaro Software
Development Meetup
Sesión #8
Noviembre, 2018

2. La finalidad del Meetup es
tener un lugar donde compartir
experiencias (técnicas o no),
ideas y tendencias en la
industria de IT
Querétaro Software
Development Meetup

3. Querétaro Software
Development Meetup
Redes:
facebook.com/groups/queretaro.software.development/
meetup.com/qro-software

4. Agenda
ReactJS y JQuery
Domain Driven Design
Presentado por Osvaldo Mercado Coss
Presentado por Alexys Hegmann
Devs VS Testers
Moderado por Edgar Fernandez.
Tester: Martín Morales y Octavio Rodríguez
Devs: Mae la Estrada y Hugo de la Rosa
Rifa y anuncios parroquiales

5. Noviembre, 2018
Domain Driven Design:
codeando con una perspectiva diferente
Presentado por Osvaldo Mercado Coss
Querétaro Software
Development Meetup

6. 6
Osvaldo Mercado Coss
● De Guadalajara, México
● Technical Project Manager en PSL Group
● Estudios en Multimedia, de alguna manera termine codeando en el
backend
○ Stack: LA|EMP, PHP + Framework, NodeJS
○ DevOps: AWS + Vagrant + Chef
○ DBs: MySQL/MariaDB, Amazon Aurora, CouchDB, Couchbase,
MongoDB y desgraciadamente SQL Server
○ Interesado en Software Escalable, DevOps & Perros
Un poco sobre mi:
Hola!
https://mx.linkedin.com/in/osvaldomercado
@omercadocoss
omercadocoss@gmail.com

8. 8
De Qué Voy a Hablar
Vamos poniendo expectativas para esta plática
UN TEMA QUE NO
ES NUEVO
“METODOLOGÍA”
DE DESARROLLO
DE SOFTWARE
No podemos llamarlo
metodología en sí, pero digamos
que es una manera de hacer
desarrollo de software
Domain Driven Design se
presentó oficialmente en
2003, por lo cual ya lleva más
de 15 años en el mundo de
desarrollo de software
UN ENFOQUE
DIFERENTE DE
CÓMO
DESARROLLAR
SOFTWARE
DESARROLLOS SUJETOS
A COLABORACIONES E
INTERPRETACIONESUNA SIMPLE
INTRODUCCIÓN A UN
TEMA BASTANTE
EXTENSO

9. 9
De Qué Voy a Hablar
Vamos poniendo expectativas para esta plática
UN MONTONAL DE
CONCEPTOS
Domain Driven Design Bounded Context Domains
Domain Experts Use Cases Context Maps
Ubiquituos Language
Contexts
Big Ball of Mud
Aggregates
Hexagonal Architectures Value Objects
Layered Architectures
Shared Kernel
Repository
Command Query Responsibility Segregation
(CQRS)
Layers

10. 10
Definiciones de Domain Driven Design (DDD)
Vamos entiendo de qué es DDD

11. 11
Definiciones de Domain Driven Design (DDD) - 2
Vamos entiendo de qué es DDD

12. 12
Podemos (tratar) de decir que DDD es...
Vamos entiendo de qué es DDD
una manera de crear modelos para resolver
problemas complejos de un dominio.
Domain Driven Design combina el negocio,
arquitectura y prácticas de desarrollo para
crear soluciones elegantes, mantenibles y
entendibles para todos los involucrados.

13. 13
Estadísticas de Proyectos en IT
Porque es necesario entender los requerimientos correctamente?

14. 14

15. 15

16. 16
¿Quien tiene una tabla / colección / módulo llamado….
Vamos entiendo de qué habla DDD
users / usuarios?

17. 17
¿Quien tiene una variable / columna llamado….
Vamos entiendo de que habla DDD
timestamp?

18. 18

19. 19
DDD busca que tu código, hable el requerimiento
Cómo empezar a trabajar con DDD

20. 20
¿Quien tiene una tabla / colección / módulo llamado….
Vamos entiendo de qué habla DDD
users / usuarios?
visitor -> lead -> customer -> recurring customer ->
target market customer -> power user -> etc...

21. 21
Ejemplo: en Marketing SÍ es importante el nombre
En el contexto de marketing, un usuario o visitante pasa por múltiples pasos para llegar a ser un customer (cliente)

22. 22
Domain Driven Design busca evitar esto
El llamado Big Ball of Mud

23. 23
…. y generar esto
Bounded Contexts que hacen sentido al negocio y al lado técnico

24. 24
OK... entonces DDD, pero ¿cómo?
Cómo empezar a trabajar con DDD
Enfocarse y entender
el core domain
1
Explorar modelos en
colaboración con
desarrolladores y
expertos del domain
2
Hablar y crear un
ubiquitous language
dentro de un bounded
context
3

25. 25
OK... entonces DDD, pero ¿cómo? (Pilares de DDD)
Recapitulando, esto es lo que creo que falló
Ubiquitous
Language
Strategic Design Tactical Design
Mismo lenguaje expresado
por personas técnicas y no
técnicas y que es
compartido en un glosario.
Diseño o planeación de los
modelos, las funciones de
estos y sus límites
Aplicación de los dos
anteriores, dentro de una
solución técnica

26. 26
OK... entonces DDD, pero dame un BENDITO ejemplo
Recapitulando, esto es lo que creo que falló
Ubiquitous
Language
Context Map
Ubiquitous
Language
Código

27. 27
OK... entonces DDD, pero dame un BENDITO ejemplo
Recapitulando, esto es lo que creo que falló
Ubiquitous
Language
Hablar el mismo lenguaje y términos, y
tener un glosario de estos que fue creado
entre expertos
técnicos y de domain

28. 28
OK... entonces DDD, pero dame un BENDITO ejemplo
Recapitulando, esto es lo que creo que falló
Ubiquitous
Language
Context Map
Crea tus dominios, basados en un
Ubiquitous Language, tus Bounded Contexts,
y ponlo en un Context Map

29. 29
OK... entonces DDD, pero dame un BENDITO ejemplo
Recapitulando, esto es lo que creo que falló
Ubiquitous
Language
Código
Pasa la lógica de negocio a Dominios,
Layers y (de ser posible) microservicios

30. 30
OK... entonces DDD, pero ¿cómo? (Layers de DDD)
Recapitulando, esto es lo que creo que falló

31. 31
Un Ejemplo de DDD
Vamos viendo un poco de código

32. 32
¿Cuándo SÍ y cuándo no usar DDD?
Algunas SUGERENCIAS recopiladas de cuando sí / no, utilizar DDD
SI NO
Prototipo
Menos de 30 use
cases
Aplicación sencilla
CRUD
One-man operation
Desarrollo en
equipo
Más de 30 use
cases*
Microservicios
¡SON
SUGERENCIAS!
Aplicación a PROD

33. 33
Lo Que He Aprendido con Domain Driven Design
Recapitulando, esto es lo que creo que me ha beneficiado al usarlo
Nosotros como
developers en veces
(¿muchas?) perdemos el
contexto de lo que el
negocio busca, por
enfocarnos en el lado
técnico
Es importante conocer
el Core Domain de tu
aplicación si la quieres
escalar, expander y
aislar
Aplicaciones donde
la complejidad de la
lógica de negocio es
alta, uno la empeora
o la mejora, no hay
término medio
Tener un mejor
entendimiento para
la creación de
paquetes / módulos
/ lógica / (micro)
servicios
independientes
Un sprint / meta de un
desarrollo (incluso
negocio) puede fallar
simplemente porque
alguien no entendió que
buscaba un stakeholder
La calidad del software
aumenta (y por ende sus
soluciones son más fáciles)
cuando más claro sea el
lenguaje, más clara es la
separación de su lógica y los
requerimientos

34. 34
Los Problemas que veo al aplicar DDD
A qué me he enfrentado
En veces no sabemos la
complejidad de una
aplicación hasta después
de construirla
(protoduction)
Nula participación de
stakeholders / management
(o aquel que tome el título
de domain expert)*
No es una habilidad o
conocimiento que se
desarrolla de un dia para
otro, es más un proceso
continuo y cambiante

35. Domain Driven Design, al igual
que
busca solucionar problemas en el
desarrollo de software.
Unit Testing TDD Agile
SCRUMBDD
Waterfall XP
Design Patterns
Continuous Integration
Kanban DevOps

36. 36
Booklet de DDD: es G-R-A-T-I-S
No se pasen de lanza, es gratis como para que no aprovechen

37. 37
DDD in PHP: Otro buen recurso
Uds deciden cuánto pagar

38. 38
DDD Europe: Historias de Implementación de DDD
Las pláticas están disponibles en línea

39. Gracias!
Bienvenidas las preguntas, comentarios, quejas y sugerencias
omercadocoss@gmail.com
https://mx.linkedin.com/in/osvaldomercado
@omercadocoss
Querétaro Software
Development Meetup
Patrocinadores del mes:

40. Links Recomendados
Recomendaciones personales acerca del tema
Domain Driven Design for Services Architecture
https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture
The Anatomy Of Domain-Driven Design - Booklet
https://leanpub.com/theanatomyofdomain-drivendesign
Practical experience with Domain Driven Design
https://github.com/DDD-
Hamburg/slides/blob/master/Practical%20experience%20with%20DDD.pdf
Can Someone Explain Domain Driven Design (DDD) In Plain English
Please? [closed]
https://stackoverflow.com/questions/1222392/can-someone-explain-domain-driven-
design-ddd-in-plain-english-please
Best Practice - An Introduction To Domain-Driven Design
https://msdn.microsoft.com/en-us/magazine/dd419654.aspx
Awesome DDD
https://github.com/heynickc/awesome-ddd
Clean Architecture with DDD Layering
https://www.slideshare.net/_leopro_/clean-architecture-with-ddd-
layering-in-php-35793127
DDD Europe
https://dddeurope.com/2017/
DDD and Microservices:At Last, Some Boundaries!
https://www.infoq.com/presentations/ddd-microservices-2016
Domain-Driven Design in a PHP project using Symfony
https://github.com/jorge07/ddd-playground
Best Practice - An Introduction To Domain-Driven Design
https://msdn.microsoft.com/en-us/magazine/dd419654.aspx