¿Qué son realmente los subdominios?

7

Al estudiar el diseño basado en dominio (DDD), he encontrado el concepto de subdominio, pero creo que todavía no lo entiendo. Mi primer entendimiento de esto fue que un subdominio es un subconjunto del dominio de la aplicación. En otras palabras, es una partición del espacio problema. He leído que hay tres tipos de subdominio:

  • subdominios principales
  • subdominios de soporte
  • subdominios genéricos.

Mi entendimiento fue algo así: elegimos el dominio de la aplicación, y es bastante complejo. Luego lo observamos y encontramos una manera de dividirlo en partes más simples, algunas de las cuales serían subdominios centrales y otras serían compatibles, mientras que otras serían genéricas.

Al buscar más información, encontré a algunas personas diciendo algo diferente: que solo existe el subdominio principal, junto con algunos subdominios genéricos y ningún subdominio de soporte en absoluto.

Así que mis preguntas son:

  1. ¿Qué son los subdominios, realmente ? ¿Mi primera comprensión es la correcta o es la segunda cosa que leo?
  2. ¿Por qué es útil esta idea de subdominios?
  3. ¿Cuáles son algunos buenos criterios para identificar subdominios? ¿Qué deberíamos tener en cuenta al decidir los subdominios para hacer un mejor uso de esta idea?

EDITAR: Buscando un poco más, encontré lo siguiente:

  

Piense en un sistema de comercio electrónico. Inicialmente, puedes decir que es una aplicación de un contexto de compras. Si observa más detenidamente, verá que también hay otros contextos, como Inventario, Entrega, Cuentas, etc.

Esto es lo que inicialmente pensé que era un subdominio. Escogemos un dominio (el dominio de compras) y lo dividimos en subdominios más simples (inventario, entrega, cuentas, etc.). Pero en el texto en cuestión, se refieren a estos como contextos. Entonces, ¿mi entendimiento anterior no es subdominios sino contextos?

He encontrado una pregunta aquí en este sitio acerca de la diferencia entre un subdominio y un contexto acotado. La respuesta indica que los subdominios son una partición del espacio del problema, mientras que los contextos son particiones del espacio de la solución. Sin embargo, separar el contexto de compra en inventario, entrega, cuentas, etc., no es una partición conceptual. Es decir, ¿está en el espacio del problema en lugar del espacio de la solución?

    
pregunta user1620696 09.02.2015 - 23:08

1 respuesta

6

Descargo de responsabilidad : no soy un experto en DDD, pero haré todo lo posible para responder sus preguntas.

Usemos un minorista de libros en línea como ejemplo. Un vendedor de libros está ofreciendo vender libros en su sitio web, pero él mismo no los imprime. En cambio, tiene una larga lista de "Proveedores de libros" que imprimen y envían los libros a su almacén, donde los empaqueta y los envía a los clientes de todo el mundo.

¿Te imaginas a los equipos trabajando en esa empresa?

  1. El equipo de listado : el equipo que selecciona qué libros deben incluir en el sitio web, dependiendo del stock de los proveedores.
  2. El equipo de cumplimiento : responsable de recopilar los pedidos del sitio web y de administrar el ciclo de vida de los pedidos.
  3. El equipo comercial : estos son los tipos que se encargan de agregar o eliminar proveedores del sistema.
  4. El equipo de marketing : responsable de las campañas y ofertas.
  5. El equipo del almacén : responsable de recopilar los libros de los proveedores y enviarlos.

Cada equipo usará sus propios términos para describir lo que está haciendo. Los equipos usarán el idioma del dominio o el "lenguaje ubicuo", como lo llama Eric Evans. Normalmente, cada equipo tendrá un modelo mental diferente de lo que es una entidad. Por ejemplo:

Listing team: BOOK(book_id, ISBN, title, price, weight, length, width )  
Fulfillment team: BOOK(book_id, totalPrice, sold_quantity)   
Shipping team: ITEM(book_id, delivery_date) --> they refer to the book entity as "item" 

Un subdominio es una parte particular del dominio, en la que algunos usuarios usan un determinado lenguaje ubicuo. Cuando el idioma cambia, esto es una indicación de que está cruzando a otro subdominio.

¿Qué pasa si dos equipos usan los mismos términos? Tanto los equipos de cumplimiento como de listado llaman al libro "libro". Deberá preguntarles: "¿Qué es un libro para usted? ¿Cuáles son sus atributos clave? ¿Cómo se utiliza?"

Las respuestas a estas preguntas darán como resultado dos modelos de dominio diferentes o similares. Cuanto mayor sea la diferencia entre los dos modelos, mayor será la indicación de que estos son dos contextos / subdominios limitados diferentes. Lo opuesto también es cierto. Cuanto más similares sean los dos modelos, mayor será la probabilidad de que formen parte del mismo subdominio.

Esto puede resultar en hallazgos muy interesantes en su modelo. Puede descubrir que dentro del subdominio de cumplimiento, los pedidos pasan a través de diferentes estados (nuevo - > solicitado - > enviado). Quizás cada uno de estos estados requiera una administración compleja y atributos diferentes, por lo que puede dividir este subdominio en varios otros subdominios.

Esto hace surgir una pregunta sobre el tamaño del subdominio (s). La respuesta es "deja que el modelo de dominio decida eso". Siempre que vea un cambio en el modelo y la UL, dibuje un límite para ese subdominio.

Recuerde que DDD es todo sobre el negocio, las personas y las comunicaciones entre ellos. Deja que eso conduzca tu modelo.

    
respondido por el Songo 11.02.2015 - 20:30

Lea otras preguntas en las etiquetas