Domain Driven Design Fundamentals
Perspectiva de alto nivel
Mejorar la interaccion con los expertos del dominio, los que conocen del negocio, hablar en conceptos del dominio en vez de tablas de base de datos.
Centrarse en un unico subdominio a la vez, cada tarea de negocio es un subdominio complejo de sus propias tareas especificas, y estos subdominios pueden tener solo una minima interaccion entre ellos. Muchas aplicaciones tratan de hacer demasiadas cosas a la vez y anadir un comportamiento adicional se vuelve mas complejo y costoso.
Implementación de cada subdominio, el principio de separación de preocupaciones (Separation of Concerns) desempeña un papel fundamental en la identificación de los subdominios, centrandose en el dominio y no en los detalles como la forma de guardar los datos en una base de datos o la forma de conectarse a un servicio en la nube. Muchas aplicaciones difunden la lógica de dominio entre la capa de persistencia y la interfaz de usuario por lo que es mas difícil de probar y mantener la lógica de negocio consistente.
Beneficios
- Centrarse en pequeñas partes individuales, casi autónomos de nuestro dominio , el software resulta mas flexible.
- El software tiende a ser mas de cerca a la comprensión del cliente del problema.
- Camino claro y manejable a través de un problemas mas complejo.
- El código es muy organizado y fácilmente testeable.
- Su beneficio real es para los dominios complejos, es mas beneficioso cuando la complejidad del dominio hace que sea difícil para los expertos del dominio comunicar sus necesidades a los desarrolladores. Eric Evans. Al invertir su tiempo y esfuerzo en el modelado del dominio, esto viene con una terminología que entiende para cada subdominio el proceso de comprensión y solución del problema se mas simple.
Desventajas
- Demasiado tiempo hablando sobre el dominio
- Demasiado tiempo clasificando lo que es verdaderamente lógica de dominio y lo que es infraestructura.
- Gran curva de aprendizaje por los nuevos principios, patrones y procesos.
- No siempre es el camino correcto se debe tener claro la complejidad del dominio de negocio y complejidad tecnica.
- Todo el equipo siga el enfoque DDD.
Mind Map
Navigation Map
