Veo mucho este término en el contexto de la arquitectura de software ("modelo de dominio", "diseño impulsado por dominio", etc.). Lo busqué en Google, pero obtengo toneladas de definiciones diferentes. Entonces, ¿qué es en realidad?
104
Respuestas:
La palabra "dominio" en el libro Diseño impulsado por dominio de Eric Evans tiene un significado específico. De eso se 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 "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 el negocio pueden trabajar juntos, y eso es lo que le preocupa cuando discute el diseño estratégico y estos subdominios.
Entonces, 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 que es la razón por la cual un cliente compraría el software frente a algún otro software. Por lo general, Evans lo ve como el dominio que contiene el menor porcentaje de código. Puedes considerarlo como el 20% más importante. Es la parte que realmente no puede comprar en el estante y podría ser solo un módulo o componente único 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 múltiples 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 la parte menos personalizada y, en cierto sentido, la parte menos importante del software. Es posible que lo haya escrito en casa, pero podría ser más eficiente simplemente comprarlo en el estante o usar un software de código abierto conocido. Esta parte del sistema probablemente no sea específica de su dominio general, por lo que, por ejemplo, si tiene un sistema de envío que enruta paquetes o un sistema de registros de salud que administra a los pacientes, el dominio genérico es la parte de estos sistemas que son comunes y solo simplemente necesita estar allí para funcionar en absoluto. Esto probablemente constituye la mayor parte del sistema en general, pero no necesariamente.
Desde una perspectiva comercial, es importante decidir cuál es su dominio principal y enfocar allí sus recursos de desarrollo. Evans tiene muchos videos, particularmente en el sitio de InfoQ, donde explica estos conceptos con más detalle.
Entonces, si bien a menudo hablamos sobre "el dominio" en el software, en el caso de DDD, no es tan simple como parece.
Debo señalar que los conceptos de DDD no necesariamente existen en la comunidad de software en general. Otros desarrolladores, autores y personas de productos pueden tener ideas y definiciones diferentes, algunas más sutiles y otras menos. Incluso otros autores que han escrito sobre DDD podrían 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.
fuente
El dominio es el contexto del mundo real en el que intentas resolver un problema usando un 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 piezas complejas utilizando una cortadora giratoria de alta velocidad". El sistema de software y hardware que logra esto se llama un molino CNC .
Otro ejemplo de un dominio es el departamento de contabilidad de una corporación.
Lecturas adicionales
Contexto limitado por Martin Fowler
fuente
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 implicarí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 o una factura o un registro de envío.
fuente
domain namestambién se conocen como dominios, creo que deberías aclarar cómo estás usando la palabra dominio aquí.Un dominio es un área de conocimiento. Puede considerarse como una actividad en la que existen problemas resueltos por su software. ( Wiki , comunidad DDD )
Eric Evans en su libro, utiliza el envío de carga para explicar qué es DDD. En su ejemplo, el dominio tiene que ver con el envío . Cómo se mueve, maneja, envía y rastrea la carga, etc. Viene con sus propias reglas, lenguaje y procesos específicos. Esos crearán modelos de dominio, objetos, servicios, etc.
Cuando crea 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 del 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 negocio es el envío de carga, el envío de carga será su dominio. Si su negocio está en autenticar y autorizar personal, este será su dominio.
fuente
Del diseño dirigido por el dominio: abordar la complejidad en el corazón del software , Eric Evans:
El modelo de dominio, entonces, es "una abstracción rigurosamente organizada y selectiva de" el conocimiento en la cabeza de un experto en dominio.
Palermo, al describir la arquitectura de la cebolla, ofreció este resumen
Fowler, a su vez, ofrece
Si está buscando definiciones más recientes, es más probable que encuentre referencias de que el modelo de dominio y el modelo de datos son diferentes . No considero que un cambio de significado sea tanto como un cambio de énfasis: modelar los comportamientos (la forma en que los datos cambian en respuesta a la información desde fuera del modelo) tiene una complejidad y variación más rica que las diferentes formas de escribir las cosas. .
fuente
Dado que probablemente ya tenga una idea de qué es el dominio, supongo que el siguiente paso que tomará será tratar de definir el subdominio, el modelo de dominio y, lo que es más importante, el contexto acotado.
Sin embargo, empiezo poniendo mi perspectiva de dominio.
Dominio
El dominio es la realidad que habitamos: sus entidades, su comportamiento, las leyes 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 especialistas en marketing presentan nuevas funciones y realizan análisis de mercado, los gerentes de cuentas clave se comunican con los clientes, los desarrolladores de software automatizan los procesos comerciales. Es por eso que el dominio se llama un espacio problemático.
Subdominios
DDD implica la descomposición del dominio en subdominios, para facilitar su modelado y comprensión. El hecho mismo de que dirijas un negocio infiere que hay al menos un valor comercial predominante. Con el que ganas dinero. Para el que comenzamos nuestro negocio. Entonces, incluso si no conoce una palabra como "Dominio principal", todavía está presente. Lo mismo se aplica a los subdominios: probablemente necesitará una contabilidad, recursos humanos, soporte técnico, pero es secundario.
Modelo de dominio
No hay necesidad de modelar subdominios extraídos en su totalidad. Hay un cierto conjunto de reglas en cada subdominio que nos interesa. Un conjunto de reglas en algún subdominio que es necesario para lograr un determinado resultado comercial se llama modelo.
Contextos limitados
Lo más importante es que el contexto acotado es un límite lógico.
Cuando se definen los subdominios y el dominio central, es hora de implementar el código. El contexto acotado define límites tangibles de aplicabilidad de algunos subdominios. Es un área donde 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.
¿Que sigue?
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 sí y cómo organizar equipos con estos conceptos en mente, probablemente le interesaría la lectura adicional .
fuente