Domain Driven Design: principios, beneficios y elementos — Primera Parte

N-Layered Architecture

En esta historia se abordarán distintos conceptos de Domain Driven Design a nivel de resumen introductorio para la utilización de esta técnica o de algunas partes de ella en los desarrollos. Al final, se enumeran distintos links y sitios consultados.

Introducción

Domain Driven Design (desde ahora DDD) es un enfoque de desarrollo de software utilizado por Eric Evans en su libro “ Domain-Driven Design — Tackling Complexity in the Heart of Software, 2004”.
Representa distintas claves, terminología y patrones utilizados para desarrollar software donde el dominio es lo más central e importante de una determinada organización.

Sus principios se basan en:

• Colocar los modelos y reglas de negocio de la organización, en el core de la aplicación
• Basar nuestro dominio complejo, en un modelo de software.
• Se utiliza para tener una mejor perspectiva a nivel de colaboración entre expertos del dominio y los desarrolladores, para concebir un software con los objetivos bien claros.

Hay distintos aspectos que pueden generar la caída de un proyecto, como la burocracia, objetivos pocos claros, problemas técnicos del equipo, problemas de elicitación de requerimientos; pero en software de un dominio complejo y una esperanza de vida un poco más larga puede ser que su caída sea debido a problemas de diseño.
Normalmente, en sistemas Enterprice que necesitan soporte y mantenimiento posterior a la puesta en producción, un mal diseño acortaría su vida útil por no poder comprender las distintas partes o poder extenderse con facilidad.

Cuando la complejidad de este dominio no se trata en el diseño, no importará que la tecnología de infraestructura esté bien concebida. Un diseño exitoso debe abordar sistemáticamente este aspecto central [dominio] del software. — what is ddd, DDD community.

¿Es posible crear software bancario complejo sin un buen conocimiento del dominio? De ninguna manera. Nunca. ¿Quién sabe sobre bancos? El arquitecto de software? No. Simplemente usa el banco para mantener su dinero a salvo y disponible cuando lo necesita. ¿El analista de software? Realmente no. Él sabe analizar un tema determinado, cuando se le dan todos los ingredientes necesarios. ¿El desarrollador? Olvídalo. ¿Quién entonces? Los banqueros, por supuesto. El sistema bancario es muy bien entendido por la gente interna, por sus especialistas. Conocen todos los detalles, todas las capturas, todos los posibles problemas, todas las reglas. Aquí es donde siempre debemos comenzar: el dominio. DDD Quickly— InfoQ

Beneficios :-)

• Comunicación efectiva entre expertos del dominio y expertos técnicos a través de Ubiquitous Languge.
• Foco en el desarrollo de un área dividida del dominio (subdominio) a través de Bounded Context’s.
• El software es más cercano al dominio, y por lo tanto es más cercano al cliente.
• Código bien organizado, permitiendo el testing de las distintas partes del dominio de manera aisladas.
• Lógica de negocio reside en un solo lugar, y dividida por contextos.
• Mantenibilidad a largo plazo.

Inconvenientes :-(

• Aislar la lógica de negocio con un experto de dominio y el equipo de desarrollo suele llevar mucho esfuerzo a nivel tiempo.
• Necesitamos un experto de dominio —¿ DDD sin Domain-Experts?
• Una curva de aprendizaje alta, con patrones, procedimientos,…
• Este enfoque solo es sugerido para aplicaciones donde el dominio sea complejo, no es recomendado para simples CRUD’s.

Aunque seguramente aplicar DDD en un estado puro puede llegar a ser complejo, seguramente se pueden adaptar estos conceptos para utilizar los necesarios o los mas interesantes a la hora de decidir nuestra arquitectura. Hay varios enfoques de aplicación de estos conceptos: Onion Architecture, Hexagonal Architecture, Clean Architecture…

Inicios

Dominio

Es el problema específico que estamos intentando resolver del mundo real. Nosotros tenemos que abstraernos de este dominio, generando una abstracción a través de un modelo. Representa todo el conocimiento de un experto; pero este conocimiento es difícil de plasmar en un desarrollo de software. Un dominio “real” tiene demasiada información que plasmar y es tarea en conjunto la decisión de las abstracciones a lograr. El primer y principal requerimiento de un modelo de dominio es ser consistente y sin contradicciones.

• Dominio principal o Core Domain, El diferenciador clave para el negocio del cliente: algo que deben hacer bien y no pueden subcontratar.
• Subdominio: separan las características o aplicaciones que su software debe admitir o debe interactuar. Es la segregación de un dominio más general en uno más acotado, cohesivo y comprensible.

El dominio se va a convertir en una capa en nuestra arquitectura, es un lugar central donde nada externo tiene que influir, complicar o distraer la idea principal: el dominio como el corazón de nuestro software.
La capa de dominio es la responsable de representar la información del negocio, la lógica del negocio, situaciones del negocio, a pesar de las dificultades que pueden conllevar la infraestructura. Es decir, nos abstraemos de nuestro detalles, que pueden ser que base de datos vamos a utilizar, como vamos a persistir, que framework frontend vamos a utilizar.

Ubiquitous Language

La comunicación efectiva entre los desarrolladores y los expertos del dominio es esencial para el proyecto. Un lenguaje común, que sea representado en el dominio, tanto como en los bounded contexts ( luego vemos que significa esto) es muy importante, para evitar tener problemas futuros y desarrollar un software exitoso, donde la comunicación sea el pilar para su obtención.

Una incompatibilidad en el lenguaje puede generar traducciones que no son necesarias, e incluso el problema de la traducción ida-vuelta: se traduce algo desde un idioma a otro, y luego cuando se intenta traducir en reversa, tiene otro significado.

A project faces serious problems when it’s languages is fractured — Eric evans

Hay que tener en cuenta que los desarrolladores, están acostumbrados a lidiar con términos relacionados a objetos, base de datos, uml, etc; y los expertos de dominio no entienden para nada este lenguaje.

Hay que trabajar para encontrar un lenguaje común entre los interesados, por ejemplo en un sistema de veterinaria (expuesto en uno de los ejemplos de los links debajo) se puede pensar en:

• Un Cliente como una persona, dueño de un animal?
• Un Cliente como un animal, que tiene un dueño persona?

Incluso también se puede ver otra discrepancia en el lenguaje, con respecto a las mascotas que se atienden, estos conceptos pueden ser semejantes según el dominio y el experto del mismo:

• paciente
• animal
• mascota
• cliente
• dueño

Es importante definir y tener muy en cuenta estos posibles “fallos” del lenguaje, ambigüedades que pueden generar errores futuros en el desarrollo de un modelo del dominio. En el ejemplo anterior, es difícil definir la brecha entre que es un cliente (un animal o una persona); a su vez esos mismos conceptos utilizados están mal expresados: no es un animal, es una mascota; no es una persona, es un dueño.

Entonces, podríamos decir que el modelo es donde debe recaer el lenguaje utilizado, no puede haber discrepancia en lo que se habla y lo que se desarrolla. Tiene que ser un recurso donde todos podamos “hablar” el mismo idioma, podríamos comparar el dominio como un diccionario del Ubiquitous Language.

La única manera que tenemos de testear y mejorar nuestro lenguaje del dominio es forzarlo en las conversaciones que tenemos con un determinado experto del dominio, para que afloren dudas y certezas, para asegurarnos que el lenguaje utilizado es el correcto.

Próximas historias

En las próximas historias se abordarán los distintos elementos y conceptos.

Segunda Parte — Elementos
Tercera Parte — Integridad

Otros links y referencias

General

DDD Quickly — InfoQ
Pluralsight — DDD fundamentals
DDD good parts — Jimmy Bogard — Video
DDD — DDD Europe ’16 — Eric Evans