Você pode falar muito sobre arquitetura de aplicativos, princípios SOLID, OOP, padrões arquiteturais como camadas ou cebola, etc. padrões de design. Ao longo da minha experiência, percebi uma coisa: quantas pessoas têm tantas opiniões. Quando você é um programador iniciante, tem muitas ambições, cresce um pouco na qualificação, tem a sensação de que sabe tudo, e tudo o que foi feito para você é "ruim" e você definitivamente fará melhor ... Mas os anos passam e a experiência adquirida sugere o contrário. Sob o corte, tentarei brevemente, e mais importante, em palavras simples, falar sobre como a arquitetura é boa. Pelo menos expansível e suportada, para mais detalhes, peço um gato…
Em primeiro lugar, para criar uma boa arquitetura do projeto, você precisa decidir sobre seus recursos:
- A arquitetura deve ser suportada.
- Extensibilidade do sistema sem muletas.
- Flexibilidade de configurações, muitas tarefas devem ser resolvidas sem alterar o código do programa.
- Confiabilidade da arquitetura.
O primeiro ponto é que a facilidade de suporte é resolvida seguindo os princípios do SOLID, basicamente, é claro, o princípio de "Exclusividade de responsabilidade"; portanto, é necessário escolher uma arquitetura baseada em microsserviços ou uma arquitetura modular de um sistema central monolítico. Não há diferença fundamental entre essas abordagens. Para o projeto em que estou trabalhando, escolhi a segunda abordagem, módulos.
O segundo ponto pode ser resolvido usando o padrão de programação observador de eventos ou despachante, pois são semelhantes entre si, portanto, não focaremos nisso. A essência do trabalho deles é lançar alguma mensagem do módulo que está sendo executado no momento e, se necessário, ouvir o módulo que precisa trabalhar com esse objeto.
O terceiro parágrafo também é resolvido de maneira bastante simples, a parte descritiva da entidade, ou seja, os atributos das entidades armazenadas separadamente da própria entidade. Esta é uma referência ao EAV (Entity Attribute Value) .Você não precisa processar todos os campos de uma entidade para lógica de negócios, alguns atributos carregam uma carga informativa, outros são usados para classificação e filtragem e apenas uma parte para criar lógica de negócios. Portanto, se a entidade estiver armazenada como EAV, podemos adicionar ou remover a qualquer momento um atributo que não precisamos.
O quarto ponto de nossos requisitos é a confiabilidade, o que significa um mínimo de "muletas" e mais automação. A maioria dos aplicativos da Web consiste em interfaces de exibição de dados, tabelas, filtros, classificação e cartões de entidade. E interfaces de entrada de dados, formulários. Portanto, vale a pena usar fábricas para formas, fábricas para mesas, fábricas para cartões. Mais automação, no final, podemos abstrair do campo da apresentação e focar na lógica de negócios e nas tarefas substantivas ...
E, assim, a conclusão sugere que, para construir uma boa arquitetura, é necessário abstrair, decidir sobre tecnologias e padrões de programação e construir uma base para iniciar o desenvolvimento ...
Agora, desenvolvemos um plano, decidimos sobre os requisitos e precisamos decidir como construir a arquitetura. De fato, não entendo todas essas arquiteturas ou cebolas em camadas. Peguei algo deles e inventei algo pessoalmente, e não vejo nada se as pessoas entenderem o que isso significa. De fato, toda a arquitetura se resume a etapas simples:
- A base é a abstração (classes abstratas e interfaces que definem o contrato de vários componentes do sistema combinados em módulos)
- Em seguida, tenho uma camada de kernel que executa os módulos e os gerencia.
- Carregando o sistema de layout
- Após iniciar o módulo, cada módulo como um microsserviço separado
Mas o que torna a arquitetura boa? A pergunta não é simples, mas se tudo for simplificado ao nível do raciocínio filosófico, essa pergunta será respondida. Após o início do aplicativo. Temos peças isoladas, módulos. Cada módulo é responsável por apenas uma funcionalidade do sistema. Abaixamos cada módulo, projetado como um aplicativo mvc e temos uma visão, controlador, modelo. E cada parte do módulo também é responsável por cada uma de suas ações. Desceremos ainda mais e veremos que a exibição também possui certas partes, são classes de fábrica e extensões de layout. De fato, os layouts também são um módulo, ele é carregado primeiro, todos os outros módulos o complementam e constroem uma interface (ou sistema de saída). Mas como você torna tudo isso menos dependente? E a resposta será óbvia para os observadores, para cada renderização do bloco do layout que eles jogam fora do evento, você só precisa ouvir esse evento, observador no seu aplicativo e adicionar a atualização necessária do bloco nas camadas e obter a saída apropriada. Muitos módulos também têm seus próprios eventos, aos quais outros módulos se inscrevem e podem adicionar / ou atualizar dados no conjunto transferido. Tudo isso leva ao fato de que, na aplicação, os módulos estão pouco conectados entre si e podem viver um sem o outro.
À luz do exposto, surge uma pergunta razoável: se um módulo escuta outro, é necessário ter algum tipo de sistema de gerenciamento de dependência para esses módulos. Ou seja, o módulo do qual outro módulo depende, devemos começar em primeiro lugar, e o módulo que é dependente, devemos executar depois. E assim nasceu uma simples implementação da dependência, criamos uma fila para iniciar os módulos e simplesmente as classificamos de tal forma que os módulos dos quais dependem outros sejam carregados antes de tudo, depois de carregar o kernel, é claro.
Em conclusão, posso dizer o seguinte. Uma boa arquitetura não é uma tarefa tão difícil e de longo prazo para economizar nela. E, no final, ajuda a gastar recursos e tempo com mais eficiência. Afinal, alterar a configuração no painel de controle é um assunto de cinco minutos. Escrever duas linhas para adicionar também não é muito tempo. Mas fazer uma conclusão, revertendo cada um, depurando grandes quantidades de dados já é um tempo muitas vezes maior que o tempo para desenvolver uma estratégia de construção de arquitetura.