Veo mucho este término en el contexto de la arquitectura de software ("modelo de dominio", "diseño impulsado por dominio", etc.). Lo he buscado en Google, pero tengo un montón de definiciones diferentes. Entonces, ¿qué es realmente?
Veo mucho este término en el contexto de la arquitectura de software ("modelo de dominio", "diseño impulsado por dominio", etc.). Lo he buscado en Google, pero tengo un montón de definiciones diferentes. Entonces, ¿qué es realmente?
La palabra "dominio" en el libro Dominio de Diseño de Eric Evans tiene un significado específico. Es de lo que trata el software.
Sin embargo, Evans va más allá. En su opinión, hay subdominios incluso con el mismo software. Y esta es la parte del libro que trata sobre el "Diseño estratégico".
Hay tres "dominios": el dominio central, el dominio de soporte y el dominio genérico. A veces se referirá a estos como subdominios.
Evans también se preocupa profundamente por el negocio real detrás del software y el libro no solo está dirigido a desarrolladores, sino también a arquitectos y gerentes que necesitan ver cómo el software y la empresa pueden trabajar juntos, y eso es lo que le preocupa cuando Discutiendo el diseño estratégico y estos subdominios.
Por lo tanto, el dominio central es la parte del software que representa tanto la ventaja competitiva como la "razón de ser" del software. Es la parte del software la que explica por qué un cliente compraría el software en lugar de otro software. Generalmente, Evans lo ve como el dominio que contiene el porcentaje más pequeño de código. Puedes considerarlo como el 20% más importante. Es la parte que realmente no se puede comprar y podría ser solo un módulo o componente del software en general.
El dominio de soporte sigue siendo importante y puede ser exclusivo de la organización, pero no es tan importante como el dominio central. Sin él, el software no será tan valioso y el núcleo depende de él. Podrían ser varios módulos en el software que usted mismo ha escrito y que realizan funciones importantes pero de apoyo al núcleo.
El dominio genérico es el menos personalizado y, en cierto sentido, la parte menos importante del software. Es posible que lo hayas escrito en casa, pero podría ser más eficiente comprarlo directamente o usar un software de código abierto conocido. Esta parte del sistema probablemente no es específica de su dominio general, por lo que, por ejemplo, si tiene un sistema de envío que enruta parcelas o un sistema de registros de salud que administre pacientes, el dominio genérico es la parte de estos sistemas que es común y justa. simplemente necesita estar allí para funcionar en absoluto. Esto probablemente constituye la mayor parte del sistema en general, pero no necesariamente así.
Desde una perspectiva empresarial, es importante decidir cuál es su dominio central y enfocar sus recursos de desarrollo allí. Evans tiene muchos videos, particularmente en el sitio de InfoQ, donde explica estos conceptos con más detalle.
Entonces, si bien a menudo hablamos de "el dominio" en el software, en el caso de DDD, no es tan simple como parece.
Debo tener en cuenta que los conceptos de DDD no existen necesariamente en la comunidad de software en general. Otros desarrolladores, autores y personas de productos pueden tener diferentes ideas y definiciones, algunas más sutiles y otras menos. Incluso otros autores que han escrito sobre DDD pueden pasar por alto estos conceptos en el libro de Evans, pero creo que los conceptos siguen siendo útiles al escribir y planificar un proyecto de software.
El dominio es el contexto del mundo real en el que está intentando resolver un problema utilizando software. Cada dominio viene con experiencia, vocabulario y herramientas que forman parte de ese dominio.
Un ejemplo específico de un dominio podría ser algo así como "el mecanizado automatizado de partes complejas con un cortador giratorio de alta velocidad". El sistema de software y hardware que logra esto se llama CNC mill .
Otro ejemplo de dominio es el departamento de contabilidad de una corporación.
Lecturas adicionales
Contexto delimitado por Martin Fowler
Simplemente significa el espacio problemático en el que está trabajando. Por ejemplo, si estuviera creando un sitio web de comercio electrónico, su dominio sería "comercio electrónico" e involucraría los procesos asociados con las prácticas de ventas de su cliente / empresa. Por lo tanto, un modelo de dominio sería algo para representar un producto, una factura o un registro de envío.
Un Dominio es un área de conocimiento. Puede tratarse como una actividad en la que existen problemas resueltos por su software. ( Wiki , Comunidad DDD )
Eric Evans en su libro, usa el transporte de carga para explicar qué es DDD. En su ejemplo, dominio es todo acerca de envío . Cómo se mueve, gestiona, despacha y rastrea la carga, etc. Viene con sus propias reglas, lenguaje y procesos específicos. Esos crearán modelos de dominio, objetos, servicios, etc.
Al crear una aplicación, tendrá algún tipo de autorización, al igual que en el mundo real del envío, no todos pueden acceder a los almacenes. La forma en que los usuarios están autorizados y cómo se otorgan los permisos puede estar fuera de la dominio , porque la información puede no ser relevante para el envío de carga.
En pocas palabras: un dominio es donde haces negocios . Si su empresa está enviando carga, la carga de envío será su dominio. Si su empresa está autentificando y autorizando personal, este será su dominio.
De Diseño basado en dominio: abordando la complejidad en el corazón del software , Eric Evans:
Cada programa de software se relaciona con alguna actividad o interés de su usuario. El área temática a la que el usuario aplica el programa es el dominio del software.
El dominio de un programa de reserva de una aerolínea implica que personas reales se suban a aviones reales.
El dominio de un programa de contabilidad es el dinero y las finanzas.
El dominio de un sistema de control de código fuente es el propio desarrollo de software.
El modelo de dominio, entonces es "una abstracción rigurosamente organizada y selectiva de" el conocimiento en la cabeza de un experto de dominio.
Palermo, al describir la arquitectura de la cebolla, ofreció este resumen
En el centro mismo vemos el Modelo de Dominio, que representa la combinación de estado y comportamiento que modela la verdad para la organización.
Fowler, a su vez, ofrece
Un modelo de objeto del dominio que incorpora tanto el comportamiento como los datos.
Si está buscando definiciones más recientes, es más probable que encuentre referencias que el modelo de dominio y el modelo de datos son diferentes . No considero que tanto un cambio de significado como un cambio de énfasis: modelar los comportamientos (la forma en que los datos cambian en respuesta a la información externa al modelo) tiene una mayor complejidad y variación que las diferentes formas de escribir las cosas. .
Como es probable que ya tengas una idea de qué es el dominio, supongo que el próximo paso que tomarás es intentar definir un subdominio, un modelo de dominio y, lo que es más importante, un contexto acotado.
Empiezo con poner mi perspectiva de dominio, sin embargo.
El dominio es la realidad que habitamos: sus entidades, su comportamiento, las leyes a las que obedecen. Existió antes que nosotros y existirá después de nosotros, de una forma u otra. Su existencia no depende de nuestra conciencia. Los profesionales de marketing presentan nuevas funciones y realizan análisis de mercado, los administradores de cuentas clave se comunican con los clientes y los desarrolladores de software automatizan los procesos de negocios. Es por eso que el dominio se llama espacio de problemas.
DDD implica la descomposición del dominio en subdominios, para facilitar su modelado y comprensión. El mismo hecho de que ejecute una empresa infiere que hay al menos un valor comercial predominante. Con el que ganas dinero. Para el que empezamos nuestro negocio. Por lo tanto, incluso si no conoce una palabra como "Dominio central", todavía está presente. Lo mismo se aplica a los subdominios: probablemente necesitará una contabilidad, recursos humanos, soporte técnico, pero es secundario.
No hay necesidad de modelar los subdominios extraídos en su totalidad. Hay un cierto conjunto de reglas en cada subdominio en el que estamos interesados. Un conjunto de reglas en algún subdominio que es necesario para lograr un determinado resultado de negocio se denomina modelo.
Lo más importante es que el contexto acotado es un límite lógico.
Cuando se definen ambos subdominios y el dominio central, es hora de implementar el código. El contexto delimitado define los límites tangibles de la aplicabilidad de algunos subdominios. Es un área donde un cierto subdominio tiene sentido, mientras que los otros no. Puede ser una charla, una presentación, un proyecto de código con límites físicos definidos por el artefacto.
Si está interesado en cómo el concepto de contexto limitado se correlaciona con el concepto de subdominio, cómo definir subdominios y contextos limitados, cómo representar su comunicación entre ellos y cómo organizar equipos con estos conceptos en mente, probablemente estaría interesado en esta lectura adicional .
Lea otras preguntas en las etiquetas domain-driven-design terminology domain-model domain-objects