Identificar limites de modelo de domínio para cada microsserviço

Dica

Esse conteúdo é um trecho do eBook, arquitetura de microsserviços do .NET para aplicativos .NET em contêineres, disponível em do .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

O objetivo ao identificar os limites e o tamanho do modelo para cada microsserviço não é chegar à separação mais granular possível, embora deva tender para pequenos microsserviços, se possível. Em vez disso, sua meta deve ser chegar à separação mais significativa orientada pelo seu conhecimento de domínio. A ênfase não está no tamanho, mas em recursos de negócios. Além disso, se houver uma coesão clara necessária para uma determinada área do aplicativo com base em um alto número de dependências, isso indicará a necessidade de um único microsserviço também. A coesão é uma maneira de identificar como separar ou agrupar microsserviços. Em última análise, enquanto você obtém mais conhecimento sobre o domínio, você deve adaptar o tamanho do seu microsserviço, iterativamente. Encontrar o tamanho certo não é um processo de uma única tentativa.

Sam Newman, um reconhecido promotor de microsserviços e autor do livro Criando Microsserviços, destaca que você deve projetar seus microsserviços com base no padrão BC (contexto limitado) (parte do design controlado pelo domínio), conforme introduzido anteriormente. Às vezes, um BC poderia ser composto por vários serviços físicos, mas não vice-versa.

Um modelo de domínio com entidades de domínio específicas se aplica em um BC ou microsserviço concreto. Um BC delimite a aplicabilidade de um modelo de domínio e dá aos membros da equipe de desenvolvedores uma compreensão clara e compartilhada do que deve ser coeso e o que pode ser desenvolvido de forma independente. Essas são as mesmas metas para microsserviços.

Outra ferramenta que informa sua escolha de design é a lei de Conway, que afirma que um aplicativo refletirá os limites sociais da organização que a produziu. Porém, às vezes, o oposto é verdadeiro: a organização da empresa é formada pelo software. Você pode precisar reverter a lei de Conway e construir os limites da maneira que você quer que a empresa seja organizada, inclinando-se para a consultoria de processo de negócios.

Para identificar contextos limitados, você pode usar um padrão DDD chamado padrão de Mapeamento de Contexto. Com o Mapeamento de Contexto, você identifica os vários contextos no aplicativo e seus limites. É comum ter um contexto e um limite diferentes para cada subsistema pequeno, por exemplo. O Mapa de Contexto é uma maneira de definir e tornar explícitos esses limites entre domínios. Um BC é autônomo e inclui os detalhes de um único domínio -details como as entidades de domínio e define contratos de integração com outros BCs. Isso é semelhante à definição de um microsserviço: ele é autônomo, implementa determinada funcionalidade de domínio e deve fornecer interfaces. É por isso que o Mapeamento de Contexto e o Padrão de Contexto Limitado são boas abordagens para identificar os limites do modelo de domínio de seus microsserviços.

Ao projetar um aplicativo grande, você verá como seu modelo de domínio pode ser fragmentado – um especialista em domínio do domínio de catálogo nomeará entidades de forma diferente nos domínios de catálogo e inventário do que um especialista em domínio de envio, por exemplo. Ou a entidade de domínio do usuário pode ser diferente em tamanho e número de atributos ao lidar com um especialista em CRM que deseja armazenar cada detalhe sobre o cliente do que para um especialista em domínio de ordenação que precisa apenas de dados parciais sobre o cliente. É muito difícil desambiguar todos os termos de domínio em todos os domínios relacionados a um aplicativo grande. Mas o mais importante é que você não deve tentar unificar os termos. Em vez disso, aceite as diferenças e a riqueza fornecidas por cada domínio. Se você tentar ter um banco de dados unificado para todo o aplicativo, as tentativas de criar um vocabulário unificado serão estranhas e não soarão adequadamente para nenhum dos vários especialistas em suas respectivas áreas. Portanto, os BCs (implementados como microsserviços) ajudarão você a esclarecer onde você pode usar determinados termos de domínio e onde você precisará dividir o sistema e criar BCs adicionais com domínios diferentes.

Você saberá que tem os limites e tamanhos certos de cada BC e modelo de domínio se tiver poucas relações fortes entre modelos de domínio e não precisar mesclar informações de vários modelos de domínio ao executar operações típicas de aplicativo.

Talvez a melhor resposta para a questão de quão grande um modelo de domínio para cada microsserviço deve ser o seguinte: ele deve ter um BC autônomo, o mais isolado possível, que permite que você trabalhe sem precisar alternar constantemente para outros contextos (modelos de outros microsserviços). Na Figura 4-10, você pode ver como vários microsserviços (vários BCs) cada um tem seu próprio modelo e como suas entidades podem ser definidas, dependendo dos requisitos específicos para cada um dos domínios identificados em seu aplicativo.

Figura 4-10. Identificando entidades e limites de modelo de microsserviço

A Figura 4-10 ilustra um cenário de exemplo relacionado a um sistema de gerenciamento de conferência online. A mesma entidade aparece como "Usuários", "Compradores", "Pagadores" e "Clientes", dependendo do contexto limitado. Você identificou vários BCs que podem ser implementados como microsserviços, com base em domínios que especialistas de domínio definiram para você. Como você pode ver, há entidades que estão presentes apenas em um único modelo de microsserviço, como Pagamentos no microsserviço de Pagamento. Isso será fácil de implementar.

No entanto, você também pode ter entidades que têm uma forma diferente, mas compartilham a mesma identidade entre os vários modelos de domínio dos vários microsserviços. Por exemplo, a entidade User é identificada no microsserviço de Gerenciamento de Conferências. Esse mesmo usuário, com a mesma identidade, é aquele chamado Compradores no microsserviço Pedidos ou aquele chamado Pagador no microsserviço pagamento e até mesmo aquele chamado Cliente no microsserviço de Atendimento ao Cliente. Isso ocorre porque, dependendo da linguagem onipresente que cada especialista em domínio está usando, um usuário pode ter uma perspectiva diferente mesmo com atributos diferentes. A entidade de usuário no modelo de microsserviço chamado Gerenciamento de Conferências pode ter a maioria de seus atributos de dados pessoais. No entanto, esse mesmo usuário na forma de Pagador no microsserviço Pagamento ou na forma de Cliente no microsserviço de Atendimento ao Cliente pode não precisar da mesma lista de atributos.

Uma abordagem semelhante é ilustrada na Figura 4-11.

Figura 4-11. Decompor modelos de dados tradicionais em vários modelos de domínio

Ao decompor um modelo de dados tradicional entre contextos limitados, você pode ter entidades diferentes que compartilham a mesma identidade (um comprador também é um usuário) com atributos diferentes em cada contexto limitado. Você pode ver como o usuário está presente no modelo de microsserviço do Gerenciamento de Conferências como a entidade Usuário e também está presente na forma da entidade Comprador no microsserviço Preços, com atributos ou detalhes alternativos sobre o usuário quando ele é, na verdade, um comprador. Cada microsserviço ou BC pode não precisar de todos os dados relacionados a uma entidade de usuário, apenas parte dele, dependendo do problema para resolver ou do contexto. Por exemplo, no modelo de microsserviço de preços, você não precisa do endereço ou do nome do usuário, apenas a ID (como identidade) e o Status, o que terá um impacto sobre os descontos ao precificar os assentos por comprador.

A entidade Seat tem o mesmo nome, mas atributos diferentes em cada modelo de domínio. No entanto, Seat compartilha identidade com base na mesma ID, conforme acontece com Usuário e Comprador.

Basicamente, há um conceito compartilhado de um usuário que existe em vários serviços (domínios), que todos compartilham a identidade desse usuário. Mas em cada modelo de domínio pode haver detalhes adicionais ou diferentes sobre a entidade de usuário. Portanto, precisa haver uma maneira de mapear uma entidade de usuário de um domínio (microsserviço) para outro.

Há vários benefícios em não compartilhar a mesma entidade de usuário com o mesmo número de atributos entre domínios. Um benefício é reduzir a duplicação, para que os modelos de microsserviço não tenham dados de que não precisam. Outro benefício é ter um microsserviço primário que possui um determinado tipo de dados por entidade para que as atualizações e consultas para esse tipo de dados sejam orientadas apenas por esse microsserviço.

AnteriorPróximo