Proceso Tipo
Expresión gráfica
Pensamiento Tipo
Expresión estructurada
Notas Tipo
Expresión eficiente
Mapa de árbol
Diagrama de soportes
Modo predeterminado
En el desarrollo de software , existe un desafío constante: a medida que la lógica de negocio se vuelve más compleja, el código se vuelve más difícil de mantener. Las primeras aplicaciones CRUD basadas en la arquitectura MVC funcionan bien, pero a medida que las necesidades del negocio se profundizan, los equipos de desarrollo se encuentran rápidamente ante un dilema: "¿Dónde debería ubicarse la lógica de negocio?".
El Diseño Orientado al Dominio (DDD, por sus siglas en inglés) se creó para resolver este problema. Propuesto por el gurú del software Eric Evans en 2003, busca construir modelos de software altamente alineados con las necesidades del negocio, utilizando el conocimiento del dominio como motor principal del diseño del sistema. DDD no es un estilo arquitectónico específico, sino una metodología de diseño completa y sistemática que simplifica dominios de negocio complejos mediante la delimitación de límites, lo que nos ayuda a definir límites claros para el dominio y la aplicación.
Este artículo explicará sistemáticamente los conceptos clave, el diseño estratégico y táctico, y la arquitectura por capas de DDD . Tanto si eres un desarrollador que se inicia en DDD como si eres un gestor de producto o un arquitecto que busca mejorar sus habilidades de diseño arquitectónico, encontrarás inspiración en él.
En los modelos de desarrollo tradicionales, la lógica de negocio suele estar entrelazada con las operaciones de la base de datos y las funcionalidades del framework, lo que resulta en una baja legibilidad del código y altos costos de mantenimiento. La idea central de DDD es separar por completo la lógica de negocio de la implementación técnica, permitiendo a los desarrolladores pensar como expertos en el negocio.
El principio fundamental de DDD es establecer un lenguaje común. Todos —incluidos desarrolladores, evaluadores, gerentes de producto y expertos en negocios— deben usar un lenguaje común unificado basado en el modelo de dominio. Esto significa que los nombres de las clases y los métodos en el código deben reflejar directamente los conceptos de negocio, en lugar de términos vagos como Procesador de Datos o Administrador. Por ejemplo, un sistema de comercio electrónico debería tener una clase Pedido y su método place(), en lugar de un Servicio de Pedidos genérico que concentra toda la lógica.
El segundo concepto fundamental de DDD es centrarse en el dominio central. En un sistema empresarial complejo, los distintos subdominios tienen diferentes valores de negocio. El dominio central es un factor clave para el éxito empresarial y requiere el mayor esfuerzo de diseño; el dominio común es la funcionalidad compartida por múltiples subdominios; y el dominio de soporte es la infraestructura que da soporte a los demás subdominios.
La práctica de DDD tiene dos dimensiones: diseño estratégico y diseño táctico. El diseño estratégico se centra en la división del dominio y la definición de límites, resolviendo el problema de "qué hacer"; el diseño táctico se centra en la implementación específica del código, resolviendo el problema de "cómo hacerlo".
Proceso de diseño orientado al dominio
Ante un sistema de gran tamaño, resulta poco práctico intentar abarcar todas las áreas de negocio con un único modelo. La parte de diseño estratégico de DDD proporciona herramientas poderosas para la partición de sistemas complejos.
Un dominio se refiere al área problemática que una empresa necesita resolver. Tomando como ejemplo un sistema de comunidad de contenido , la " comunidad de contenido " en su totalidad constituye un dominio, el cual puede dividirse en múltiples subdominios como gestión de usuarios , lectores , pagos y comunidad . Entre ellos, la comunidad podría pertenecer al dominio principal, mientras que los pagos pertenecerían al dominio de soporte.
Conclusión clave: En el diseño estratégico, es importante identificar cuáles son los subdominios que constituyen las competencias centrales del negocio y concentrar los recursos en ellos.
DDD - Diagrama de subdominios de la comunidad de contenido
Este es el patrón estratégico más importante en DDD (Data Demand and Decision Making). Define claramente el alcance de la aplicación de un modelo, es decir, "¿dentro de qué límites se refiere esta palabra?". Por ejemplo, en el contexto de los bienes de comercio electrónico, "producto" tiene atributos como precio, descripción y categoría; mientras que en el contexto de la logística, "producto" se centra más en el peso y el volumen.
Cada contexto delimitado constituye un "límite semántico" independiente, que posee un lenguaje común unificado y un modelo de dominio. De este modo, el sistema se descompone en múltiples módulos altamente cohesionados y débilmente acoplados.
Principio clave: Los contextos delimitados aclaran su relación con otros contextos mediante el mapeo de contextos, evitando así la contaminación del modelo.
[Modelado de estrategias DDD] - Delimitación de contextos delimitados
El DDD (Análisis de Dependencias de Datos) y la arquitectura de microservicios se complementan a la perfección. Un contexto delimitado bien diseñado es, naturalmente, un candidato idóneo para un microservicio. Por el contrario, dividir un sistema indiscriminadamente según capas técnicas puede fácilmente derivar en un monolito distribuido: los servicios pueden estar separados, pero el acoplamiento persiste. En una arquitectura de microservicios, un servicio no debe ser menor que un agregado ni mayor que un contexto delimitado.
Dentro del contexto delimitado, DDD proporciona un conjunto de herramientas de modelado táctico para la construcción de modelos de dominio.
Una entidad es un objeto con un identificador único y un ciclo de vida. Por ejemplo, aunque un usuario cambie de nombre, su identificador único permanece invariable y sigue siendo la misma entidad. Las entidades suelen emplear un modelo de enriquecimiento, donde los comportamientos empresariales se encapsulan dentro de la entidad.
Los objetos de valor carecen de identificadores únicos y se distinguen únicamente por sus valores de atributo, siendo generalmente inmutables. Por ejemplo, la cantidad (Dinero) se determina por la moneda y el valor; dos valores de Dinero con la misma cantidad y moneda son intercambiables. El uso adecuado de objetos de valor puede reducir la complejidad del sistema; por ejemplo, las direcciones, las direcciones de correo electrónico y los números de teléfono pueden modelarse como objetos de valor.
Una agregación es un conjunto de entidades y objetos de valor relacionados que se gestionan como un todo. La raíz de la agregación es la entidad central dentro de la misma, responsable de mantener la coherencia. Por ejemplo, la raíz de la agregación Pedido gestiona las entidades Artículo de pedido y Pago; todo acceso a los artículos del pedido debe realizarse a través de Pedido.
Principios de diseño de agregados: Las transacciones dentro de un mismo agregado deben mantener la coherencia; las referencias a otros agregados deben realizarse únicamente mediante identificadores, evitando referencias directas entre ellos. Los agregados deben diseñarse para que sean lo más pequeños posible.
Este es un concepto que suele resultar confuso para los principiantes. Los servicios de dominio gestionan comportamientos propios del dominio que no pueden atribuirse a entidades ni a objetos de valor. Pertenecen a la capa de dominio, mantienen la pureza del dominio y no implican detalles técnicos. Por ejemplo, TransferService gestiona las transferencias entre cuentas; no pertenece a ninguna entidad de cuenta específica, pero constituye la lógica de negocio fundamental.
Los servicios de aplicación coordinan los objetos y servicios del dominio, gestionan los flujos de trabajo de la aplicación y pertenecen a la capa de aplicación. Los servicios de aplicación no tienen estado y son responsables de la programación de casos de uso, la gestión de transacciones y la autenticación de seguridad, pero no contienen reglas de negocio.
El repositorio actúa como puente entre la capa de dominio y la capa de infraestructura. En la capa de dominio se define como una interfaz abstracta, mientras que la capa de infraestructura implementa la lógica de almacenamiento específica. El repositorio solo expone métodos de acceso por agregación y no expone detalles del ORM.
Los eventos de dominio son eventos de negocio significativos que ocurren dentro de un dominio y que pueden usarse para activar la lógica de negocio posterior y desacoplar módulos.
Diagrama de diseño táctico orientado al dominio
DDD recomienda una arquitectura por capas, que normalmente consta de cuatro capas: capa de interfaz de usuario, capa de aplicación, capa de dominio y capa de infraestructura.
Este componente se encarga de interactuar con los usuarios, recibir solicitudes y devolver respuestas. En una aplicación web, se corresponde con el controlador, pero solo se encarga de la validación de parámetros y el formato de los resultados, y no contiene lógica de negocio.
Los objetos de dominio se coordinan para completar los casos de uso de negocio, gestionando los límites de las transacciones, la seguridad y la autenticación. Los servicios de la capa de aplicación permanecen sin estado, solo llaman a los servicios de dominio o a los métodos raíz agregados y no contienen reglas de negocio.
El núcleo de DDD incluye todas las reglas y modelos de negocio. Define raíces agregadas, entidades, objetos de valor y servicios de dominio para garantizar la integridad de la lógica de negocio.
Proporciona soporte para la implementación técnica, como acceso a bases de datos, colas de mensajes y llamadas a API externas. Mediante el principio de inversión de dependencias, la capa de dominio define las interfaces y la capa de infraestructura las implementa, logrando un aislamiento completo entre la lógica de negocio y la implementación técnica.
En una arquitectura DDD por capas, las dependencias se dirigen desde el exterior hacia el interior: la capa de interfaz de usuario depende de la capa de aplicación, la capa de aplicación depende de la capa de dominio, y la interfaz de la capa de infraestructura se define mediante la capa de dominio a través de la inversión de dependencias. La capa de dominio no depende de ningún framework o tecnología específica, lo que permite reemplazar la lógica de negocio principal con tecnologías alternativas sin necesidad de modificaciones.
En la implementación práctica del Diseño Orientado al Dominio (DDD), la visualización es un paso crucial para ayudar a los equipos a alcanzar un consenso. Ya sea para la delimitación del contexto en la fase de diseño estratégico o para la construcción del modelo de dominio en la fase de diseño táctico, los diagramas claros son indispensables. ProcessOn, como herramienta profesional de diagramación en línea, permite visualizar de forma eficiente todo el proceso de las arquitecturas DDD.
1. Ve a tu página de perfil de ProcessOn y crea un "Diagrama de flujo", o busca palabras clave como diseño de arquitectura DDD en la comunidad de plantillas.
2. A la izquierda, en "Más gráficos", puedes seleccionar categorías gráficas como diagramas de flujo y diagramas UML para añadirlas a la biblioteca gráfica. Arrastra y suelta formas como rectángulos y círculos desde la biblioteca gráfica al lienzo y usa líneas con flechas para conectar diferentes elementos y expresar dependencias.
3. Cuando se selecciona uno o más elementos, la barra de herramientas superior puede usar diferentes colores para distinguir los distintos niveles del modelo, así como para realizar ajustes de diseño, como la alineación gráfica y la configuración de capas.
4. Una vez completado el diagrama, puede hacer clic en el botón "Compartir colaboración" en la esquina superior derecha para compartir el diagrama de arquitectura DDD con colegas o clientes y así facilitar la iteración continua del modelo. También puede exportarlo como imagen de alta resolución, PDF, SVG u otros formatos para futuras consultas.
El diseño orientado al dominio no es solo un conjunto de patrones técnicos o especificaciones arquitectónicas; es una revolución en la forma de pensar y una metodología sistemática para abordar la complejidad intrínseca del software. Nos enseña que el desarrollo de software no comienza con la creación de tablas, sino con la comprensión del negocio.
Al definir estratégicamente los límites del dominio y diseñar tácticamente un modelo de dominio altamente cohesivo, junto con una arquitectura en capas que aísla la lógica de negocio de la implementación técnica, DDD puede mejorar significativamente la mantenibilidad y la escalabilidad de sistemas empresariales complejos. Especialmente en la era de los microservicios, el método de partición de contexto delimitado que proporciona DDD es la mejor práctica para la descomposición científica de microservicios.
Diagrama de flujo de mapas mentales colaborativos en línea gratuito
