2. En un enfoque tradicional de diseño…
DOMAIN DRIVEN DESING
Presumimos que los casos de
uso son suficientes para que…
…los ingenieros de software
construyan un sistema.
3. En un enfoque tradicional de diseño…
DOMAIN DRIVEN DESING
Presumimos que los casos de
uso son suficientes para que…
…los ingenieros de software
construyan un sistema.
5. ¿De que se trata DDD?
DOMAIN DRIVEN DESING
Es un enfoque de desarrollo de software para necesidades complejas
enfocado en conectar profundamente la implementación con un modelo de negocios en
constante evolución
partiendo de la base del trabajo en equipo, la comunicación y colaboración constante
entre expertos técnicos (Ingenieros de Software) y expertos del dominio (Usuarios)
en contextos acotados de negocio
utilizando para ello un lenguaje ubicuo
“El software puede fallar por dos motivos: creamos las cosas mal o creamos las
cosas incorrectas”
6. Para implementar DDD:
DOMAIN DRIVEN DESING
• Lo primordial es mantener contacto constante y permanente con el experto del negocio utilizando un lenguaje ubicuo
• Mapea los dominios y sepáralos en subdominios
• Mira el panorama general del Proceso de Negocio As Is, aprendiendo sobre el dominio del problema
• Crea contextos acotados (Bounded Contexts) entre subdominios
• Idealmente, debe haber un equipo, una base de código y una base de datos diferentes para cada uno de los Bounded
Contexts
• Dado que todos estarían trabajando dentro de su propio Bounded Context, serían libres de cambiar cualquier cosa
dentro de este (siempre trabajando con los Expertos del Dominio y utilizando Lenguaje Ubicuo)
• Para todos los asuntos transversales que se comparten entre diferentes Bounded Contexts (lo llamamos Shared
Kernel), cualquier cambio debe ser conocido y acordado entre todos los equipos en cada Bounded Context afectado
(nuevamente, teniendo en cuenta que los equipos son conformados entre los expertos técnicos de sistemas y los
expertos del domino del negocio)
• Mantente siempre enfocado en los comportamientos del dominio en lugar del estado del dominio (favorece un
modelo rico sobre un modelo anémico)
7. ¿Y qué no debemos hacer al implementar DDD?
DOMAIN DRIVEN DESING
1. Tener una vista centrada en los datos al modelar el dominio del problema.
Por lo general, el modelo de datos es lo primero que un arquitecto o ingeniero de software
comenzará a diseñar. Siempre consideran que los datos son lo más importante porque los
datos son todo lo que necesitamos informar. Con DDD, debemos cambiar este paradigma.
Los datos en sí mismos no tienen sentido. Sólo la lógica da a los datos un significado, y los
mismos datos pueden tener un significado diferente en contextos diferentes. Por lo tanto,
debemos comenzar con contexto y lógica en lugar de datos
8. ¿Y qué no debemos hacer al implementar DDD?
DOMAIN DRIVEN DESING
2. Centrarse en los detalles de la implementación como entidades, objetos de
valor, servicios, fábricas y repositorios en lugar de los conceptos básicos del
negocio.
Las entidades, los objetos de valor, los repositorios, etc., no tienen un significado hasta que
definimos el lenguaje ubicuo, los contextos delimitados y las interfaces. Si comenzamos
pronto con los detalles de implementación como las entidades, entonces es muy probable
que el resultado sea un dominio anémico rodeado de una gran cantidad de servicios y lógica
empresarial dispersos por todas partes, que generan a su vez DEUDA TÉCNICA.
9. ¿Y qué no debemos hacer al implementar DDD?
DOMAIN DRIVEN DESING
3. Usar términos y conceptos genéricos o técnicos de desarrollo al implementar
la aplicación.
Nunca debemos usar conceptos como save, update, delete, handle, manage, etc. Esos
conceptos son conceptos técnicos/abstractos y sin un significado específico para el usuario.
En cambio, debemos mantenernos enfocados en los conceptos de negocio. Los conceptos
mencionados anteriormente (es decir, save, update, etc.) no están relacionados con los
conceptos de negocios.
10. ¿Y qué no debemos hacer al implementar DDD?
DOMAIN DRIVEN DESING
4. Sobreestimar las transacciones de bases de datos en lugar de centrarse en los
procesos y transacciones comerciales.
En DDD, las transacciones comerciales son más importantes que las transacciones de Bases
de Datos. Las transacciones de Bases de Datos son ACID, muy consistentes y de corta
ejecución, mientras que las transacciones comerciales no lo son. De hecho, en la vida real
solo conocemos las transacciones comerciales. Nunca pensemos en transacciones DB. En su
lugar, siempre pensemos en los procesos del mundo real, en las acciones (comportamientos)
y sus posibles resultados, y cómo compensar las acciones si se producen fallas.
11. ¿Y qué no debemos hacer al implementar DDD?
DOMAIN DRIVEN DESING
1. Tener una vista centrada en los datos al modelar el dominio del problema.
2. Centrarse en los detalles de la implementación como entidades, objetos de
valor, servicios, fábricas y repositorios en lugar de los conceptos básicos del
negocio.
3. Usar términos y conceptos genéricos o técnicos de desarrollo al implementar
la aplicación.
4. Sobreestimar las transacciones de bases de datos en lugar de centrarse en los
procesos y transacciones comerciales.
