Andrey Kopylov , nosso diretor técnico, nos diz qual a abordagem que a equipe de desenvolvimento web da AREALIDEA usa para projetar a arquitetura de aplicativos e qual é a qualidade do KISS Architecture, seu próprio desenvolvimento.
Existem muitas abordagens para projetar uma arquitetura de aplicativo. MVC, DDD, Arquitetura Limpa e muitos outros.
O MVC é adequado para pequenas aplicações. Quando você tenta escalar, o MVC se transforma na arquitetura mais comum no mundo da TI - Big Lump of Dirt .
DDD é uma ótima arquitetura, mas ninguém entende. A menos que o próprio criador e alguns arquitetos. O objetivo da arquitetura é torná-la compreensível para todos os desenvolvedores.
Arquitetura Limpa é uma ótima arquitetura, mas sua implementação completa faz sentido para aplicativos enormes. Para pequenas e médias, me pareceu muito complicado.
Tendências atuais - a transição para serviços e microsserviços - nesse contexto, a Arquitetura Limpa está se tornando muito pesada.
Parece, então, vamos usar o MVC para microsserviço e parar com isso. Mas não, essa bicicleta não nos convém.
Componentes
A bicicleta para projetos em nossa agência é montada a partir de peças de reposição de diferentes abordagens arquitetônicas.
Aqui estão os componentes necessários para criar uma estrutura compreensível e conveniente:
- Roteadores
- Controladores
- Visualizações
- Serviços
- Modelos
Camadas
Roteador
O roteador é responsável por solicitações de roteamento. O tamanho do roteador e seu número indica indiretamente o tamanho do seu aplicativo. Para uma aplicação monolítica grande, pode haver mais de uma camada de roteadores.
O roteador está presente em qualquer arquitetura, mas geralmente implicitamente. E como o óbvio é melhor que o implícito, vale a pena retirá-lo - para torná-lo parte integrante da arquitetura.
Controlador
O controlador é uma camada entre o roteador e os serviços. Não deve haver lógica comercial no controlador.
Cada controlador controla apenas uma entidade. Se você precisar de mais entidades, precisará adicionar outro controlador.
O número e o tamanho dos controladores indicam indiretamente o tamanho do seu aplicativo. A camada vertical sob o controlador pode ser separada em um microsserviço separado.
Visualizações
Vista está em uma camada com o controlador, é responsável pela exibição final dos dados. O controlador depois de receber dados do serviço transfere os dados para o modo de exibição e retorna o modo de exibição para exibição.
No caso extremo, o View é JSON, XML e formatos semelhantes.
Serviços
Somente um serviço pode conter lógica de negócios. Um serviço geralmente se refere a apenas um modelo. Um serviço pode chamar outro serviço.
A camada de serviço é dividida em comandos e consultas (comandos e consultas). Essa é a abordagem padrão para o CQRS .
Um serviço executa apenas uma função. Pode haver qualquer número de funções privadas e apenas um público. O nome do serviço começa com um verbo. Exemplos: GetUsers, GetPostById, UpdateUser, PublishPost. É o nome do serviço que sugere a separação correta da funcionalidade.
Nas consultas, colocamos serviços que não modificam o banco de dados. A consulta contém uma função pública de obtenção . Em Comandos, colocamos serviços que alteram o banco de dados. O comando contém uma função pública de execução .
Modelos
O modelo contém apenas a lógica mais simples associada à leitura e salvamento de dados. Além disso, essas manipulações podem não estar relacionadas ao banco de dados.
Se o modelo funcionar com um banco de dados, um modelo servirá apenas uma ou várias tabelas.
Receitas
Microserviço
Um microsserviço, no meu entendimento, deve gerenciar apenas uma entidade. Portanto, a arquitetura do microsserviço mais simples terá a seguinte aparência:
- um roteador;
- um controlador;
- múltiplas visões;
- vários serviços;
- um modelo.
Serviço
O serviço é um mini aplicativo. Contém:
- um roteador;
- vários controladores;
- múltiplas visões;
- vários serviços;
- Vários modelos.
Monólito
Monólito é uma ótima aplicação. Ninguém ama monólitos por causa de sua monstruosidade. Um monólito é justificado se você seguir a primeira abordagem do monólito. Nesse estado, seu aplicativo pode permanecer por algum tempo.
O monólito contém:
- um SuperRouter;
- vários roteadores comuns;
- muitos controladores;
- muitas visões, muitos serviços;
- muitos modelos.
Começa a parecer um pouco assustador. Aqui você pode ver claramente a separação vertical adicional das camadas. Isso permite que o aplicativo permaneça ainda gerenciado e mantido. Serrar um monólito em partes se torna uma tarefa puramente mecânica.
Para preservar a harmonia da arquitetura, você precisa:
- Adicione um roteador de nível superior que resolverá os caminhos globais - SuperRouter.
- Distribua arquivos em uma estrutura por módulo. Ou seja, de acordo com o futuro cortado em serviços individuais.
Teste
Dentro da estrutura da arquitetura em consideração, apenas os serviços estão sujeitos a testes rigorosos - apenas a lógica de negócios é incorporada a eles. E você só precisa se molhar modelos.
Se você deseja testar algo diferente de serviços, provavelmente o local da lógica foi escolhido incorretamente.
Conclusão
Na minha opinião, o KISS Architecture é adequado para 80% dos projetos e fornece uma evolução suave do projeto.
Essa abordagem arquitetônica ficará clara para todos os desenvolvedores e, para sua aplicação na prática, você não precisa ler livros pesados sobre DDD.