No último artigo, concentrei-me na arquitetura em camadas DDD. Ao mesmo tempo, também mencionei que existem muitos tipos de modelos de arquitetura de microsserviços. Será que você percebeu?
Esses modelos arquitetônicos possuem alto valor de referência em nossa aplicação prática. Então, hoje vamos reunir os três modelos de arquitetura de arquitetura em camadas DDD (se você esquecer os detalhes), arquitetura elegante e arquitetura hexagonal, comparar e analisar, ver como fazer bom uso deles e nos ajudar a projetar Alta coesão e baixa acoplando plataforma intermediária e arquitetura de microsserviços.
arquitetura limpa
A Arquitetura Limpa também é conhecida como "Arquitetura Cebola". Por que é chamada de arquitetura cebola? Dê uma olhada na imagem abaixo e você entenderá. As camadas de uma arquitetura limpa são como fatias de cebola, o que incorpora a ideia de design em camadas.
Na arquitetura limpa, os círculos concêntricos representam diferentes partes do software aplicativo, de dentro para fora estão o modelo de domínio, serviços de domínio, serviços de aplicação e os conteúdos mais periféricos fáceis de alterar, como interface de usuário e infraestrutura.
O princípio mais importante de uma arquitetura limpa é o princípio da dependência , que define as dependências de cada camada.Quanto menor for a dependência, maior será o nível do código e mais recursos essenciais ele terá. As dependências de código do círculo externo só podem apontar para o círculo interno, e o círculo interno não precisa saber nada sobre o círculo externo.
Na arquitetura cebola, as funções de cada camada são divididas da seguinte forma:
- O modelo de domínio realiza a lógica de negócios central do domínio e encapsula as regras de negócios no nível empresarial. O corpo principal do modelo de domínio é uma entidade. Uma entidade pode ser um objeto com métodos ou uma coleção de estruturas e métodos de dados.
- Os serviços de domínio implementam lógica de negócios complexa envolvendo diversas entidades.
- O serviço de aplicação implementa a composição e orquestração de serviços relacionadas às operações do usuário, que inclui regras de processos de negócios específicas da aplicação, e encapsula e implementa todos os casos de uso do sistema.
- A camada mais externa fornece principalmente a capacidade de adaptação, e a capacidade de adaptação é dividida em adaptação ativa e adaptação passiva. A adaptação ativa realiza principalmente a adaptação de usuários externos, páginas da web, processamento em lote e testes automatizados para acesso à lógica de negócios interna. A adaptação passiva visa principalmente realizar a adaptação da lógica de negócios central ao acesso a recursos básicos, como bancos de dados, caches, sistemas de arquivos e middleware de mensagens.
- O modelo de domínio, o serviço de domínio e o serviço de aplicativo no círculo vermelho formam juntos a principal capacidade de negócios do software.
arquitetura hexagonal
A arquitetura hexagonal também é conhecida como "arquitetura do adaptador de porta". Rastrear a origem da arquitetura de microsserviços geralmente envolve a arquitetura hexagonal.
A ideia central da arquitetura hexagonal é que as aplicações interajam com o exterior por meio de portas. Acho que essa também é a principal razão para a prevalência de gateways de API na arquitetura de microsserviços.
Ou seja, na arquitetura hexagonal da figura abaixo, a lógica de negócios central (modelo de aplicativo e domínio) no círculo vermelho é completamente isolada de recursos externos (incluindo APP, aplicativo da web e recursos de banco de dados, etc.), e interage apenas por meio de adaptadores. Ele resolve o problema de intercalação de código entre a lógica de negócios e a interface do usuário e consegue uma boa separação entre front-ends e back-ends. As dependências de cada camada da arquitetura hexagonal são as mesmas da arquitetura elegante, que depende de fora para dentro.
A arquitetura hexagonal divide o sistema em duas camadas: hexágono interno e hexágono externo.As funções dessas duas camadas são divididas da seguinte forma:
- O hexágono no círculo vermelho implementa a lógica comercial central do aplicativo;
- O hexágono externo completa a interação e o acesso de aplicativos externos, drivers e recursos básicos, fornecendo serviços para aplicativos front-end na forma de adaptação ativa de API e implementando acesso a recursos para recursos básicos na forma de adaptação passiva de inversão de dependência.
Uma porta da arquitetura hexagonal pode corresponder a vários sistemas externos, e diferentes sistemas externos podem usar adaptadores diferentes, e os adaptadores são responsáveis pela conversão do protocolo.
Isso permite que o aplicativo seja usado de maneira consistente por usuários, programas, testes automatizados e scripts em lote.
Comparação e análise de três modelos de arquitetura de microsserviços
Embora os modelos arquitetônicos de arquitetura em camadas DDD, arquitetura organizada e arquitetura hexagonal tenham expressões diferentes, não se confunda com sua aparência.As ideias de design desses três modelos arquitetônicos são exatamente o princípio de alta coesão e baixo acoplamento na arquitetura de microsserviços. personificação perfeita deles, e o que brilha neles é a ideia de design centrada no modelo de domínio.
Vejamos a imagem acima e analisemos os três modelos de arquitetura em combinação com o diagrama.
Por favor, preste atenção aos wireframes vermelhos na figura. Eles são linhas divisórias muito importantes, encontradas em todas as três arquiteturas. Sua função é isolar a lógica de negócios central de aplicativos externos e recursos básicos.
A lógica de negócios principal é implementada principalmente dentro da caixa vermelha, mas a lógica de negócios principal também é diferente.Alguma lógica de negócios pertence à capacidade do modelo de domínio, e outra pertence ao caso de uso orientado ao usuário e à capacidade de orquestração de processos. De acordo com essa diferença funcional, dividimos a camada de aplicação e a camada de domínio nessas três arquiteturas para realizar lógicas de negócios diferentes.
A camada de domínio implementa o modelo de domínio e implementa a lógica de negócios central do modelo de domínio. Ela pertence ao modelo atômico. Ela precisa manter a estabilidade do modelo de domínio e da lógica de negócios e fornecer serviços de domínio estáveis e refinados externamente, portanto, está no centro da arquitetura.
A camada de aplicação implementa casos de uso e processos relacionados às operações do usuário e fornece externamente serviços de API de granulação grossa. É como uma engrenagem que adapta a aplicação de primeiro plano e a camada de domínio, recebe os requisitos de primeiro plano, responde e se ajusta a qualquer momento e tenta evitar a transmissão dos requisitos de primeiro plano para a camada de domínio. A camada de aplicação, como uma engrenagem, está localizada entre a aplicação em primeiro plano e a camada de domínio.
Pode-se dizer que essas três arquiteturas levam em consideração as mudanças nos requisitos de front-end e a invariância do modelo de domínio. As demandas estão em constante mudança, mas sempre há regras a seguir. Mudanças na experiência do usuário, nos hábitos operacionais, no ambiente de mercado e nos processos de gerenciamento geralmente levam a mudanças na lógica e nos processos da interface. Mas, em geral, não importa como o front-end mude, a lógica do domínio central basicamente não mudará muito se não houver grandes mudanças na empresa, de modo que o modelo de domínio é relativamente estável e os casos de uso e processos serão ajustados em a qualquer momento de acordo com os requisitos da aplicação externa. Compreendendo bem esta lei, saberemos como projetar a camada de aplicação e a camada de domínio.
O modelo arquitetônico controla o impacto das mudanças na demanda no sistema, de fora para dentro, em camadas, e reduz gradualmente o impacto da demanda de fora para dentro. O front-end orientado ao usuário pode responder rapidamente às necessidades externas de ajuste e liberação, que é flexível e mutável.A camada de aplicação realiza a rápida adaptação e lançamento de processos de negócios através da composição e orquestração de serviços, reduzindo a necessidade de transmissão para o domínio camada e mantém a estabilidade a longo prazo da camada de domínio.
A vantagem deste design é óbvia, ou seja, pode garantir que a lógica de negócio central da camada de domínio não será ajustada devido a mudanças nos requisitos e processos externos, o que é muito útil para estabelecer um front-end flexível e estável. arquitetura de médio porte.
Vendo isso, você já adivinhou a chave para o design da plataforma intermediária e dos microsserviços? A resposta que dou é: design razoável em camadas de modelo de domínio e microsserviços . Então, qual é a sua resposta?
Observando a plataforma intermediária e o design de microsserviços a partir de três modelos de arquitetura
Combinando os pontos comuns desses três modelos de arquitetura de microsserviços, deixe-me falar sobre alguma experiência em plataforma intermediária e design de microsserviços.
A plataforma intermediária é essencialmente um subdomínio do domínio, que pode ser o domínio principal, ou o domínio geral ou domínio de suporte. Acredita-se geralmente que a plataforma intermediária de Ali corresponde ao domínio geral do DDD, e as capacidades do público em geral são precipitadas na plataforma intermediária para fornecer serviços gerais compartilhados ao mundo exterior.
Como um subdomínio, a estação intermediária pode ser ainda decomposta em subsubdomínios.Depois que o subdomínio é decomposto em um tamanho apropriado e o contexto limitado é dividido por meio da tempestade de eventos, os microsserviços podem ser definidos e os microsserviços são usados para realizar os recursos da estação intermediária. Superficialmente, parece não haver conexão entre DDD, plataforma intermediária e microsserviços. Na verdade, o relacionamento deles é muito próximo. Juntos, eles podem ser usados como um sistema teórico para sua plataforma intermediária e design de microsserviços.
1. A construção da China e de Taiwan deve centrar-se no modelo de domínio
O middle office precisa considerar o compartilhamento e a reutilização de capacidades na perspectiva de toda a empresa.
Ao projetar a plataforma intermediária, precisamos estabelecer modelos de domínio de todos os contextos limitados na plataforma intermediária.A evolução da arquitetura e a recombinação de funções serão consideradas durante o processo de modelagem DDD. O processo de estabelecimento do modelo de domínio dividirá claramente os limites lógicos e físicos (microsserviços) do negócio e da aplicação. Os resultados do modelo de domínio afetarão o modelo de sistema subsequente, o modelo de arquitetura e o modelo de código e, em última análise, afetarão a divisão de microsserviços e a implementação do projeto.
Portanto, no design intermediário, devemos primeiro focar no modelo de domínio e colocá-lo no centro.
2. Os microsserviços devem ter uma camada arquitetural razoável
O design de microsserviços deve ter uma ideia de design em camadas, permitir que cada camada desempenhe suas funções e estabelecer um relacionamento fracamente acoplado entre as camadas.
Não coloque lógica independente de domínio na camada de domínio para garantir a pureza da camada de domínio e a estabilidade da lógica de domínio e evitar poluir o modelo de domínio. Não coloque a lógica de negócios do modelo de domínio na camada de aplicativo, o que fará com que a camada de aplicativo seja muito grande e, eventualmente, o modelo de domínio perderá o foco. Se for realmente inevitável, podemos introduzir uma camada anticorrosiva para adaptar e converter os sistemas antigos e novos.Após a conclusão do período de transição, o código da camada anticorrosiva pode ser descartado diretamente.
Já entendemos o método de camadas dentro dos microsserviços, então existe alguma dependência hierárquica entre os microsserviços? Como conseguir integração de serviços entre microsserviços?
Alguns microsserviços podem ser integrados a aplicativos front-end para concluir negócios específicos juntos. Esses são microsserviços em nível de projeto. E alguns são microsserviços de estágio intermediário com uma única responsabilidade. Os processos de negócios de nível empresarial precisam ser combinados com vários desses microsserviços para serem concluídos. Este é um microsserviço de estágio intermediário de nível empresarial. Devido à complexidade diferente dos dois tipos de microsserviços, os métodos de integração também serão diferentes.
Microsserviços em nível de projeto
Os componentes internos dos microsserviços em nível de projeto seguem o modelo de arquitetura em camadas. A lógica central do modelo de domínio é implementada na camada de domínio, e a combinação e orquestração de serviços é implementada na camada de aplicativo.Os serviços são fornecidos para aplicativos front-end por meio de gateways de API para alcançar a separação entre front-end e back-end . No entanto, os microsserviços em nível de projeto podem chamar outros microsserviços. Você pode ver na imagem abaixo, por exemplo, um microsserviço B em nível de projeto chama o microsserviço de autenticação A para concluir o login e a autenticação de autorização.
Normalmente, a integração entre microsserviços em nível de projeto ocorre na camada de aplicação dos microsserviços, e os serviços de aplicação chamam os serviços de aplicação publicados por outros microsserviços no gateway API. Observe o serviço de aplicação B na caixa vermelha do microsserviço B na figura abaixo: além de combinar e orquestrar seus próprios serviços de domínio, ele também pode combinar e orquestrar serviços de aplicação de microsserviços externos. Ele só precisa publicar o serviço orquestrado no gateway da API para o front-end chamar, para que o front-end possa acessar diretamente seus próprios microsserviços.
Microsserviços de estágio intermediário de nível empresarial
Os processos de negócios de nível empresarial são muitas vezes concluídos através da colaboração de vários microsserviços de estágio intermediário.Como integrar microsserviços de estágio intermediário cruzado?
A integração de microsserviços de nível intermediário de nível empresarial não pode completar a composição e orquestração de serviços entre microsserviços dentro de um determinado microsserviço, como os microsserviços em nível de projeto.
Podemos adicionar uma camada sobre os microsserviços de médio porte. Veja a imagem abaixo. A camada adicionada está localizada na caixa vermelha. Sua principal função é lidar com a composição e orquestração de serviços em microsserviços de médio porte, bem como a coordenação. entre serviços, também pode completar a adaptação de aplicações front-end em diferentes canais. Se eu expandir seu escopo de negócios, posso torná-lo uma plataforma de serviços para diferentes setores e canais.
Poderíamos muito bem pegar emprestado o termo BFF (Backend for Frontends) e chamá-lo de microsserviços BFF por enquanto. Existe uma grande diferença entre os microsserviços BFF e outros microsserviços, ou seja, não possui modelo de domínio, portanto não haverá camada de domínio neste microsserviço. Os microsserviços BFF podem realizar as principais funções da camada de aplicativo e da camada de interface do usuário, completar a combinação e orquestração de serviços de vários microsserviços de médio porte e podem se adaptar aos requisitos de diferentes front-ends e canais.
3. Dissociação e adaptação de aplicações e recursos
No padrão de design tradicional centrado em dados, os aplicativos dependerão fortemente de recursos básicos, como bancos de dados, caches e sistemas de arquivos.
É justamente pela forte dependência entre eles que uma vez que substituímos os recursos básicos, isso terá um grande impacto na aplicação, por isso é necessário dissociar a aplicação e os recursos.
Na arquitetura de microsserviços, a dissociação da camada de aplicação, camada de domínio e camada base é alcançada por meio do modelo de warehouse e do método de design de inversão de dependência. No design do aplicativo, consideraremos simultaneamente a adaptação do código dos recursos básicos.Uma vez que os recursos da infraestrutura mudam (como a mudança do banco de dados), podemos proteger o impacto das mudanças de recursos no código de negócios e eliminar a dependência do negócio lógica nos recursos básicos. Em última análise, reduza o impacto das alterações de recursos nos aplicativos.
Resumir
Hoje explicamos em detalhes a arquitetura elegante e a arquitetura hexagonal, e comparamos e analisamos três modelos de arquitetura de microsserviços, incluindo a arquitetura em camadas DDD, resumimos suas características comuns e classificamos o meio Vários pontos-chave da modelagem de plataforma e design de arquitetura de microsserviços, nós teremos uma descrição mais detalhada da implementação do design posteriormente.
Não é difícil ver pelo conteúdo de hoje: a arquitetura em camadas DDD, a arquitetura elegante e a arquitetura hexagonal estão todas centradas no modelo de domínio, implementando uma arquitetura em camadas, e a lógica de negócios central interna é isolada e desacoplada de aplicativos e recursos externos. Lembre-se desta ideia de design, ela será de grande utilidade no futuro.