Domain-Driven Design es un concepto introducido por el programador Eric Evans en 2004 en su libro Domain-Driven Design: Tackling Complexity in Heart of Software .
Es un enfoque para la arquitectura del diseño de software al observar el software en un enfoque de arriba hacia abajo. Antes de discutir el tema en detalle, intentemos enfocar un poco la luz y entender qué significa dominio en este contexto.
¿Qué es Dominio?
La palabra Dominio utilizada en el contexto del desarrollo de software se refiere a los negocios . En el proceso de desarrollo de aplicaciones, se suele utilizar el término lógica de dominio o lógica empresarial. Básicamente, la lógica de negocios es un área de conocimiento en torno a la cual gira la lógica de la aplicación. La lógica comercial de una aplicación es un conjunto de reglas y pautas que explican cómo los objetos comerciales deben interactuar entre sí para procesar datos modelados.
Nota:
un dominio en el campo de la ingeniería de software es un negocio en el que se pretende construir la aplicación.
Diseño basado en dominios:
supongamos que hemos diseñado un software utilizando toda la tecnología e infraestructura más recientes y nuestra arquitectura de diseño de software es fabulosa, pero cuando lanzamos este software al mercado, es el usuario final quien decide si nuestro sistema es excelente o no. Además, si el sistema no resuelve la necesidad comercial, no sirve para nadie; No importa qué tan bonito se vea o qué tan bien arquitecture su infraestructura. Según Eric Evans , cuando estamos desarrollando software, nuestro enfoque no debe estar principalmente en la tecnología, sino que debe estar principalmente en los negocios. Recuerda,
No es trabajo del cliente saber lo que quiere” – Steve Jobs
El diseño basado en dominios habla de dos tipos de herramientas de diseño, la primera son las herramientas de diseño estratégico y la otra son las herramientas de diseño táctico. Los programadores o desarrolladores generalmente manejan herramientas de diseño táctico, pero si tenemos conocimiento y una buena comprensión de las herramientas de diseño estratégico, nos ayudarán a diseñar un buen software.
La mayoría de los marcos de trabajo de la familia de datos Spring se crean teniendo en cuenta el enfoque de diseño basado en dominios.
Diseño Estratégico:
Las herramientas de diseño estratégico nos ayudan a resolver todos los problemas que están relacionados con el modelado de software. Es un enfoque de diseño similar al diseño orientado a objetos en el que nos vemos obligados a pensar en términos de objetos. Con el diseño estratégico aquí nos vemos obligados a pensar en términos de un contexto.
Contexto:
Podemos considerar que esta es una palabra en inglés que se refiere a las circunstancias de un evento, incidente, declaración o idea, y en términos de los cuales se podría determinar su significado.
Además del contexto, el diseño estratégico también habla de modelo, lenguaje ubicuo y contexto acotado. Estos son términos comunes que se utilizan en el diseño estratégico del diseño impulsado por el dominio. Entendamos cada uno por uno.
- Modelo:
actúa como una lógica central y describe aspectos seleccionados del dominio. se utiliza para resolver problemas relacionados con ese negocio. - Lenguaje ubicuo:
un lenguaje común utilizado por todos los miembros del equipo para conectar todas las actividades del equipo en torno al modelo de dominio. Considérelo como usar verbos y sustantivos comunes para clases, métodos, servicios y objetos mientras habla con expertos del dominio y miembros del equipo. - Contexto acotado:
se refiere a las condiciones de contorno del contexto. Es una descripción de un límite y actúa como un umbral dentro del cual se define y aplica un modelo de dominio particular.
Diseño táctico:
el diseño táctico habla sobre los detalles de implementación, es decir, el dominio de modelado. Generalmente se ocupa de los componentes dentro de un contexto acotado. Es posible que hayamos escuchado o usado cosas como servicios, entidades, repositorios y fábricas. Todos han sido acuñados y popularizados por el diseño impulsado por dominios. El proceso de diseño táctico ocurre durante la fase de desarrollo del producto.
Analicemos algunas de las herramientas de diseño táctico importantes. Estas herramientas son conceptos de alto nivel que se pueden utilizar para crear y modificar modelos de dominio.
- Entidad:
un programador que ha trabajado en principios orientados a objetos puede conocer conceptos llamados clase y objetos. Aquí una entidad es una clase que tiene algunas propiedades. La instancia de estas clases tiene una identidad global y mantiene la misma identidad a lo largo de la vida. Recuerde que puede haber un cambio en el estado de la propiedad, pero la identidad nunca cambia. En resumen, una entidad implementa alguna lógica comercial y podría identificarse de manera única mediante una ID. En el contexto de la programación, generalmente persiste como una fila en la base de datos y consta de objetos de valor. - Objetos de valor:
estos son objetos inmutables y livianos que no tienen ninguna identidad. Los objetos de valor reducen la complejidad al realizar cálculos complejos, aislando la lógica computacional pesada de las entidades.En la imagen de arriba, el Usuario es una entidad y la Dirección es un objeto de valor, la dirección puede cambiar muchas veces pero la identidad del Usuario nunca cambia. Cada vez que se cambie una dirección, se creará una nueva instancia y se asignará al usuario.
- Servicios:
un servicio es una clase sin estado que encaja en otro lugar que no sea una entidad u objeto de valor. En resumen, un servicio es una funcionalidad que existe en algún lugar entre las entidades y los objetos de valores, pero no está relacionada con una entidad ni con los objetos de valores. - Agregados:
cuando tenemos un proyecto más grande, el gráfico de objetos se vuelve grande. Cuanto más grande es el gráfico de objetos, más difícil es mantenerlo. Un agregado es una colección de entidades y valores que se encuentran bajo un único límite de transacción. Los agregados básicamente controlan el cambio y tienen una entidad raíz llamada raíces agregadas. La entidad raíz gobierna la vida útil de otras entidades en agregados.En el ejemplo anterior, si la entidad raíz Usuario u Orden se elimina, otras entidades asociadas con la entidad raíz no serán de utilidad y esta información asociada también se eliminará. Eso significa que un agregado siempre es de naturaleza consistente y esto se hace con la ayuda de eventos de dominio. Los eventos de dominio se generan para garantizar la coherencia final.
En el ejemplo anterior, si se ha cambiado la dirección del Usuario, también debe reflejarse en el Pedido. Para hacerlo, podemos activar un evento de dominio de Usuario a Pedido para que el Pedido actualice la dirección para que tengamos coherencia final y el Pedido sea finalmente coherente.Otros ejemplos de agregados y raíz agregada podrían ser comentarios en una publicación, detalles de preguntas y respuestas, detalles de transacciones bancarias, etc. La herramienta ORM, como hibernación , usa muchos agregados al crear una relación de uno a muchos o de muchos a uno.
- Fábricas y repositorios:
las fábricas y los repositorios se utilizan para manejar agregados. Las fábricas ayudan a administrar el inicio del ciclo de vida de los agregados, mientras que los repositorios ayudan a administrar la mitad y el final del ciclo de vida de un agregado. Las fábricas ayudan a crear agregados, mientras que los repositorios ayudan a conservar los agregados. Siempre debemos crear un repositorio por raíz agregada pero no para todas las entidades.
Las fábricas son patrones de diseño de GoF. Las fábricas son útiles, pero no obligatorias en el contexto de la regla de agregado.
Ventajas del diseño basado en dominios:
- Mejora nuestro oficio.
- Proporciona flexibilidad
- Prefiere los dominios a la interfaz.
- Reduce la brecha de comunicación entre equipos a través del lenguaje ubicuo
Desventajas del diseño basado en dominios:
- Requiere un profesional que tenga una sólida experiencia en el dominio.
- Alienta al equipo a seguir prácticas iterativas.
Publicación traducida automáticamente
Artículo escrito por asadaliasad y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA