DDD: Mis primeras impresiones.
¿Qué es DDD?.
DDD es una técnica de diseño de sistemas que busca reducir la ambigüedades y malos entendidos que surgen cuando la parte dueña del proceso real (el cliente o cualquier conocedor del problema) y la parte técnica (el equipo de desarrollo) no logran unificar una solución a un problema complejo. Los dueños del proceso, por lo general, piensan y modelan la solución en términos de alto nivel, mientras que el equipo de desarrollo modela o piensa la solución desde el bajo nivel. DDD busca crear un puente entre estas dos posiciones, inicialmente unificando términos y conceptos, después dividiendo el problema en subsistemas o subdominios. En términos generales es aplicar el principio de única responsabilidad a nivel subsistema en lugar de hacerlo a nivel componente.
Los conceptos y comportamientos de alto nivel, los cuales aportan valor son el principal activo de un sistema, DDD tiene esto en cuenta y el diseño gira en torno a estos, todo lo demás pasa a un segundo orden de importancia.
Detrás de DDD esta SOLID.
DDD busca lo mismo que otras técnicas de diseño de software alternativas y es: administrar la complejidad del software a través del diseño y la construcción, paralelamente entregar la solución a la problemática que el cliente espera, en resumen: entregar el producto correcto y un buen producto.
He encontrado muchas similitudes y equivalencias con otras metodologías y técnicas. La primera que me viene a la mente es la que menciona Robert C. Martin en Clean Architecture, definir un sistema en términos de políticas y detalles. Políticas son las reglas de negocio (conceptos y comportamientos de alto nivel), detalle es todo lo demás. Usando los principios de SOLID, se busca hacer software con baja complejidad, bajo acoplamiento y una alta cohesión.
En lo que llevo aprendiendo de DDD he visto los principios de SOLID en acción a otro nivel. No solo en el ámbito de creación de componentes.
DDD tiene su propia terminología y puedes malinterpretarla.
Uno de los problemas que te puedes encontrar al aprender acerca de DDD es querer cruzar conceptos de lenguajes, frameworks o metodologías con esta técnica. Entidades, Objetos de valor, contextos, dominios, servicios, etc. ; todo esto representa un concepto único en DDD. Por ejemplo: Entity Framework de .Net maneja el concepto de entidades y contextos en la comunicación con las bases de datos. Este parecido puede darte la falsa idea de que emplear EF en el modelado y diseño de la solución la va a convertir en DDD, esto, obvio, no es así.
DDD está pensado para problemas complejos.
Destaca mucho la ineficiencia de DDD para resolver problemas simples, esta es una técnica pensada para resolver problemas grandes y complejos. Usar DDD para un pequeño sistema CRUD (altas, bajas y cambios), o sistemas con poca o nula interacción con el exterior puede hacer más compleja la resolución del problema.
Autor imagen: Bernard Spragg. NZ
Referencias:
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
2 respuestas a «DDD: Mis primeras impresiones.»
Los comentarios están cerrados.