¿Qué son realmente los subdominios?

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

• subdominios centrales
• subdominios de apoyo
• subdominios genéricos

Mi comprensión fue algo así: elegimos el dominio de la aplicación, y es bastante complejo. Luego lo miramos y descubrimos una forma 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, he encontrado algunas personas que dicen algo diferente: que existe un solo subdominio central, junto con algunos subdominios genéricos y ningún subdominio compatible.

Entonces mis preguntas son:

1. ¿Qué son realmente los subdominios ? ¿Es mi primera comprensión la correcta, o es la segunda cosa que leo?
2. ¿Cómo es útil esta idea de subdominios?
3. ¿Cuáles son algunos buenos criterios para identificar subdominios? ¿Qué debemos 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 se puede decir que es una aplicación de un contexto de compra. Si observa más de cerca, verá que también hay otros contextos, como Inventario, Entrega, Cuentas, etc.

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

He encontrado una pregunta aquí en este sitio sobre 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?

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 ofrece vender libros en su sitio web, pero él 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 los equipos que trabajan en esa empresa?

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

Cada equipo usará sus propios términos para describir lo que está haciendo. Los equipos utilizarán el idioma del dominio o el "Idioma 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 el que algunos usuarios usan un determinado lenguaje ubicuo. Cuando el idioma cambia, esto indica que está cruzando a otro subdominio.

¿Qué pasa si dos equipos usan los mismos términos? Tanto los equipos de cumplimiento como los de listado llaman libro "libro". Tendrás que preguntarles, "¿qué es un libro para ti? ¿Cuáles son sus atributos clave? ¿Cómo se usa?"

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, más probable es 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 por 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 cuál debería ser el tamaño de los subdominios. La respuesta es "dejar que el modelo de dominio decida eso". Siempre que vea un cambio en la UL y el modelo, dibuje un límite para ese subdominio.

Recuerde que DDD tiene que ver con el negocio, las personas y las comunicaciones entre ellos. Deja que eso conduzca tu modelo.