Identificar limites de modelo de domínio para cada microsserviço
Gorjeta
Este conteúdo é um trecho do eBook, .NET Microservices Architecture for Containerized .NET Applications, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
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 você deva tender para microsserviços pequenos, se possível. Em vez disso, seu objetivo deve ser chegar à separação mais significativa guiada pelo conhecimento do seu domínio. A ênfase não está no tamanho, mas sim nas capacidades 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 indica a necessidade de um único microsserviço também. A coesão é uma forma de identificar como separar ou agrupar microsserviços. Em última análise, enquanto você ganha mais conhecimento sobre o domínio, você deve adaptar o tamanho do seu microsserviço, iterativamente. Encontrar o tamanho certo não é um processo único.
Sam Newman, um reconhecido promotor de microsserviços e autor do livro Building Microservices, destaca que você deve projetar seus microsserviços com base no padrão Bounded Context (BC) (parte do design controlado por domínio), conforme introduzido anteriormente. Às vezes, um BC pode ser composto por vários serviços físicos, mas não o contrário.
Um modelo de domínio com entidades de domínio específicas aplica-se dentro de um BC ou microsserviço concreto. Um BC delimita 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 do que pode ser desenvolvido de forma independente. Estes são os mesmos objetivos para os 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 o produziu. Mas à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 deseja que a empresa seja organizada, inclinando-se para a consultoria de processos 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 pequeno subsistema, por exemplo. O Mapa de Contexto é uma forma de definir e explicitar esses limites entre domínios. Um BC é autônomo e inclui os detalhes de um único domínio - detalhes como as entidades de domínio - e define contratos de integração com outros BCs. Isso é semelhante à definição de um microsserviço: é autônomo, implementa determinada capacidade de domínio e deve fornecer interfaces. É por isso que o Mapeamento de Contexto e o padrão de Contexto Delimitado 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 do 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 todos os detalhes sobre o cliente do que para um especialista em domínio de pedidos 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 um vocabulário unificado serão estranhas e não soarão bem para nenhum dos vários especialistas em domínio. Portanto, os BCs (implementados como microsserviços) ajudarão você a esclarecer onde você pode usar certos termos de domínio e onde você precisará dividir o sistema e criar BCs adicionais com domínios diferentes.
Você saberá que obteve os limites e tamanhos corretos de cada BC e modelo de domínio se tiver poucos relacionamentos fortes entre modelos de domínio, e geralmente não precisa mesclar informações de vários modelos de domínio ao executar operações típicas de aplicativos.
Talvez a melhor resposta para a questão de quão grande deve ser um modelo de domínio para cada microsserviço seja a seguinte: ele deve ter um BC autônomo, o mais isolado possível, que permita que você trabalhe sem ter que mudar constantemente para outros contextos (modelos de outros microsserviços). Na Figura 4-10, você pode ver como vários microsserviços (vários BCs) têm 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 do 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 poderiam ser implementados como microsserviços, com base em domínios que os especialistas em domínio definiram para você. Como você pode ver, existem entidades que estão presentes apenas em um único modelo de microsserviço, como Pagamentos no microsserviço de pagamento. Estes serão fáceis 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 Usuário é identificada no microsserviço Gerenciamento de Conferências. Esse mesmo usuário, com a mesma identidade, é o chamado Compradores no microsserviço de Pedidos, ou o chamado Pagador no microsserviço de Pagamento, e até mesmo o chamado Cliente no microsserviço de Atendimento ao Cliente. Isso ocorre porque, dependendo da linguagem ubíqua que cada especialista em domínio está usando, um usuário pode ter uma perspetiva 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 Pagamento de microsserviço ou na forma de Cliente no Atendimento ao Cliente de microsserviço pode não precisar da mesma lista de atributos.
Uma abordagem semelhante é ilustrada na Figura 4-11.
Figura 4-11. Decompondo 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 de Gerenciamento de Conferências como a entidade Usuário e também está presente na forma da entidade Comprador no microsserviço de Preços, com atributos alternativos ou detalhes sobre o usuário quando ele é realmente 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 a ser resolvido 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 o ID (como identidade) e o status, o que terá impacto nos 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, a Seat partilha a identidade com base no mesmo ID, tal como acontece com o Utilizador e o Comprador.
Basicamente, há um conceito compartilhado de um usuário que existe em vários serviços (domínios), que compartilham a identidade desse usuário. Mas em cada modelo de domínio pode haver detalhes adicionais ou diferentes sobre a entidade do 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ços não tenham dados de que não precisem. Outro benefício é ter um microsserviço primário que possui um determinado tipo de dados por entidade, de modo que as atualizações e consultas para esse tipo de dados sejam conduzidas apenas por esse microsserviço.
