O que são subdomínios, realmente?

Ao estudar o design controlado por domínio (DDD), deparei-me com o conceito de subdomínio, mas acho que ainda não o entendi. Meu primeiro entendimento disso foi que um subdomínio é um subconjunto do domínio do aplicativo. Em outras palavras, é uma partição do espaço do problema. Eu li que existem três tipos de subdomínio:

• subdomínios principais
• subdomínios de suporte
• subdomínios genéricos.

Meu entendimento foi mais ou menos assim: escolhemos o domínio do aplicativo, e ele é bastante complexo. Depois, analisamos e descobrimos uma maneira de particioná-lo em partes mais simples, algumas das quais seriam subdomínios principais e outras seriam de suporte, enquanto outras seriam genéricas.

Ao procurar mais informações, encontrei pessoas dizendo algo diferente: existe apenas um subdomínio principal, juntamente com alguns subdomínios genéricos e nenhum subdomínio de suporte.

Então, minhas perguntas são:

1. O que são subdomínios, realmente ? Meu primeiro entendimento é o correto ou é a segunda coisa que eu leio?
2. Como essa ideia de subdomínios é útil?
3. Quais são alguns bons critérios para identificar subdomínios? O que devemos ter em mente ao decidir sobre subdomínios, a fim de fazer melhor uso dessa idéia?

EDIT: Pesquisando um pouco mais, encontrei o seguinte:

Pense em um sistema de comércio eletrônico. Inicialmente, você pode dizer que é uma aplicação de um contexto de compras. Se você olhar mais de perto, verá também outros contextos, como estoque, entrega, contas etc.

Isto é o que eu pensava inicialmente que era um subdomínio. Escolhemos um domínio (o domínio de compras) e o dividimos em subdomínios mais simples (inventário, entrega, contas etc.). Mas no texto em questão, eles se referem a eles como contextos. Então, meu antigo entendimento não é subdomínios, mas contextos?

Encontrei uma pergunta aqui neste site sobre a diferença entre um subdomínio e um contexto limitado. A resposta afirma que os subdomínios são uma partição do espaço do problema, enquanto os contextos são partições do espaço da solução. No entanto, separar o contexto de compras em estoque, entrega, contas etc. não é uma partição conceitual. Ou seja, está no espaço do problema e não no espaço da solução?

Isenção de responsabilidade : não sou especialista em DDD, mas farei o meu melhor aqui para responder às suas perguntas.

Vamos usar um varejista de livros on-line como exemplo. Um vendedor de livros está se oferecendo para vender livros em seu site, mas ele não os imprime. Em vez disso, ele tem uma longa lista de "Fornecedores de livros" que imprimem e despacham os livros para seu armazém, onde os empacota e os envia para os clientes em todo o mundo.

Você poderia imaginar as equipes trabalhando nessa empresa?

1. A equipe de listagem : a equipe que seleciona quais livros eles devem listar no site, dependendo do estoque dos fornecedores.
2. A equipe de atendimento : responsável por coletar os pedidos no site e gerenciar o ciclo de vida dos pedidos.
3. A equipe comercial : esses são os responsáveis ​​por adicionar ou remover fornecedores do sistema.
4. A equipe de marketing : responsável pelas campanhas e ofertas.
5. A equipe do armazém : responsável por coletar livros dos fornecedores e enviá-los.

Cada equipe usará seus próprios termos para descrever o que está fazendo. As equipes usarão o idioma do domínio ou o "Ubiquitous Language", como Eric Evans o chama. Normalmente, cada equipe terá um modelo mental diferente do que é uma entidade. Por exemplo:

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" 

Um subdomínio é uma parte específica do domínio, na qual alguns usuários usam uma certa linguagem ubíqua. Quando o idioma muda, isso indica que você está atravessando para outro subdomínio.

E se duas equipes usarem os mesmos termos? As equipes de atendimento e listagem chamam o livro "livro". Você terá que perguntar a eles: "o que é um livro para você? Quais são seus principais atributos? Como é usado?"

As respostas a essa pergunta resultarão em dois modelos de domínio diferentes ou semelhantes. Quanto maior a diferença entre os dois modelos, mais indicação de que esses são dois subdomínios / contextos limitados diferentes. O oposto também é verdade. Quanto mais semelhantes forem os dois modelos, maior a probabilidade de que eles façam parte do mesmo subdomínio.

Isso pode resultar em descobertas muito interessantes em seu modelo. Você pode descobrir que, dentro do subdomínio de atendimento, os pedidos passam por diferentes estados (novo -> solicitado -> enviado). Talvez cada um desses estados exija gerenciamento complexo e atributos diferentes; portanto, você pode dividir esse subdomínio em vários outros subdomínios.

Isso levanta uma questão sobre qual deve ser o tamanho dos subdomínios. A resposta é "deixe o modelo de domínio decidir isso". Sempre que vir uma alteração no UL e no modelo, desenhe um limite para esse subdomínio.

Lembre-se de que o DDD tem tudo a ver com negócios, pessoas e comunicação (ões) entre eles. Deixe isso guiar seu modelo.