cartilha
Quando o sistema está no estágio de 0 a 1, para permitir que o produto fique on-line rapidamente, a camada do sistema geralmente não é uma área importante do desenvolvimento de software. No entanto, à medida que o negócio se torna mais complexo e um grande número de os códigos são emaranhados e acoplados, a lógica não ficará clara neste momento. , Os módulos são interdependentes, a escalabilidade é ruim e o problema de alterar uma parte afeta todo o corpo.
Quando o sistema for de 1 a 100...0, o sistema se tornará particularmente complicado e a estratificação do sistema será colocada em pauta neste momento, então o que é estratificação? Por que fazer camadas? Como camada de software? Quais são os princípios orientadores para camadas de software? Este artigo o levará a encontrar as respostas uma a uma.
O que é uma arquitetura em camadas?
A arquitetura em camadas é uma ideia de design de dividir e conquistar e um paradigma de arquitetura baseado em camadas. Geralmente, os desenvolvedores dividem um sistema em vários módulos ou subsistemas com base no conceito de dividir e conquistar; em seguida, dividem os módulos divididos em grupos de dependências relacionadas e relacionamentos hierárquicos de acordo com o nível de negócios; para realizar funções de acordo com grupos funcionais e isolamento acoplado. Chamamos esse paradigma de paradigma de arquitetura em camadas.
Exemplo de arquitetura em camadas
Figura 1 Diagrama de arquitetura do sistema Android
|
Figura 2 Diagrama de relacionamento da camada de arquitetura do Android
|
O exemplo mais típico de uma arquitetura em camadas é o sistema operacional Android, que é uma operação móvel de código aberto baseada em Linux. O sistema Android adota um paradigma de camadas de cima para baixo. A Figura 1 é o diagrama oficial da arquitetura do sistema Android fornecido pelo Google, e A Figura 2 é o sistema Android A relação entre as cinco camadas do diagrama.
As cinco camadas da arquitetura do sistema operacional Android são:
- aplicativos da camada de aplicação
- Estruturas da camada da estrutura do aplicativo
- Bibliotecas c/c++ nativas da camada de tempo de execução do sistema/tempo de execução do Android
- camada de abstração de hardware camada de abstração de hardware
- Kernel Linux LayerLinux Kernel
Por que fazer camadas?
No estágio de desenvolvimento de software de 0 a 1, os desenvolvedores geralmente alcançam o isolamento do negócio por meio do isolamento do módulo. Neste momento, o isolamento do módulo é o "foco" do isolamento do software; e quando o sistema é de 1 a 100...0, porque o sistema está em um estado de supergrande escala, a segregação por módulo não é mais prática. Atualmente, quase todos os softwares isolam os "pontos de preocupação" por meio de camadas para lidar com mudanças em diferentes requisitos, para que tais mudanças possam ser realizadas de forma independente, trazendo assim os seguintes benefícios aos desenvolvedores:
- Alta coesão: o design em camadas pode simplificar o design do sistema, permitindo que diferentes camadas se concentrem em seus próprios negócios
- Baixo acoplamento: as camadas interagem por meio de interfaces ou APIs, e a parte confiável não precisa conhecer os detalhes da parte dependente
- Reutilização: alta capacidade de reutilização pode ser alcançada após a estratificação
- Escalabilidade: a arquitetura em camadas pode facilitar a expansão horizontal
Além disso, o paradigma da arquitetura em camadas também é uma ferramenta poderosa para isolar a complexidade dos negócios e a complexidade técnica. "Padrões, princípios e práticas de design orientado a domínio" tem essa discussão:
Para evitar transformar a base de código em uma grande bola de lama e, assim, enfraquecer a integridade do modelo de domínio e, por fim, a usabilidade, a arquitetura do sistema precisa suportar a separação da complexidade técnica da complexidade do domínio. As razões para mudanças em implementações técnicas são claramente diferentes das razões para mudanças na lógica de domínio, o que leva a problemas de infraestrutura e lógica de domínio que mudam em taxas diferentes.
As "mudanças em taxas diferentes" aqui na verdade significam que as razões para as mudanças são diferentes, o que é a personificação do Princípio da Responsabilidade Única (SRP), razão pela qual o negócio e a infraestrutura devem ser separados. suas mudanças são diferentes.
Resumindo, a essência do paradigma em camadas é simplificar questões complexas, permitir que cada camada de código desempenhe suas funções com base no princípio da responsabilidade única e realizar a interação entre objetos de camada relacionados com base na ideia de design de "alta coesão e baixo acoplamento". Isso melhora a capacidade de manutenção e escalabilidade do código. No software de pequena escala, o foco do isolamento de responsabilidade são os módulos ou classes. No projeto de software de grande escala, o foco do isolamento de responsabilidade são as camadas. Isolamos as alterações por meio de camadas, que é o objetivo final da camada de software.
Como fazer camadas?
Existem muitos princípios na camada de software. Aqui, o autor primeiro analisa e apresenta os quatro princípios da camada de software e, em seguida, apresenta uma camada gradualmente refinada proposta na abordagem de arquitetura "Arquitetura de Software Orientada a Padrões: Volume 1 (Sistema de Padrões)" .
Princípios orientadores
A razão pela qual o software precisa ser em camadas é, na verdade, nossa regra cognitiva subconsciente: orientado para a máquina, orientado para o usuário. As máquinas são a base sobre a qual o software é executado e os sistemas que construímos atendem aos usuários. Quanto mais alto o nível de arquitetura em camadas, mais orientado ao negócio e ao usuário é seu nível de abstração; quanto mais baixo o nível de arquitetura em camadas, mais unificado se torna seu nível de abstração e mais orientado a dispositivos. A arquitetura clássica de três camadas é derivada desta regra cognitiva: a camada superior concentra-se na experiência e interação do usuário; a camada intermediária concentra-se em aplicativos e lógica de negócios; a camada inferior concentra-se em recursos e dispositivos externos. Portanto, o primeiro princípio da divisão em camadas é dividir diferentes negócios em camadas com base nas preocupações.
O segundo princípio da estratificação é isolar as alterações. Ao estratificar, determine os limites das camadas de acordo com os diferentes motivos das alterações, pelo menos para garantir que o impacto das alterações em cada camada seja minimizado, mas esse é apenas o objetivo mínimo e o objetivo máximo é proibir estritamente a interação entre as camadas. Por exemplo, a modificação do banco de dados deve afetar apenas o modelo de dados da camada de infraestrutura e o modelo de domínio da camada de domínio, mas se apenas a lógica de acesso ao banco de dados da camada de infraestrutura for modificada, isso não deve afetar o modelo de domínio do camada de domínio.
O terceiro princípio da estratificação é que as camadas devem ser ortogonais.O chamado ortogonal não significa que não haja relação entre as duas camadas, mas que as duas devem ser duas linhas retas que se cruzam perpendicularmente. O único ponto de dependência entre os dois é a interseção das duas linhas, ou seja, o ponto de colaboração entre as duas camadas. Este ponto de colaboração é a interface abstrata entre as camadas. Duas retas ortogonais, não importa qual reta seja estendida, não terão qualquer influência sobre a outra reta (a projeção da reta). Se não for ortogonal, quando uma linha é estendida, sempre se projetará para outra linha, o que significa que a outra linha é afetada pela extensão desta linha.
Outro princípio de camadas é garantir que os componentes da mesma camada estejam no mesmo nível de abstração. Este princípio é emprestado do padrão "abordagem combinatória" proposto por Kent Beck no livro "Smalltalk Best Practice Patterns". Esse padrão exige que todas as operações em um método estejam no mesmo nível de abstração, o que é chamado de "Princípio de nível único de abstração (SLAP)".
orientação em camadas
Depois de entender muitos princípios de camadas, deixe-me apresentar um método de arquitetura em camadas gradualmente refinado proposto em "Arquitetura de Software Orientada a Padrões: Volume 1 (Sistema de Padrões)".
Na primeira etapa, são definidos critérios abstratos para dividir as tarefas em diferentes camadas. No desenvolvimento de software real, as camadas inferiores são geralmente divididas de acordo com a distância do hardware, e as camadas superiores são divididas de acordo com a complexidade do conceito.
O segundo passo é determinar o nível da camada de abstração de acordo com o critério de abstração.
A terceira etapa é nomear cada camada e atribuir tarefas.
A quarta etapa é padronizar os serviços e garantir que quaisquer componentes ou módulos não cruzem camadas. Ao colocar mais componentes nos níveis mais altos, os níveis mais baixos são mantidos estreitos. Formando assim uma pirâmide invertida.
A quinta etapa é melhorar a divisão hierárquica e executar repetidamente da primeira à quarta etapas.
A sexta etapa é padronizar a interface abstrata de cada camada para garantir que, para a camada J+1, a camada J seja uma "caixa preta". Projete uma interface unificada que possa fornecer todos os serviços da camada J.
O sétimo passo é determinar a estrutura de cada camada. Determinar a estrutura hierárquica não apenas garante que o relacionamento entre as camadas seja razoável, mas também requer que os componentes dentro da camada tenham granularidade apropriada. Dessa forma, evita-se a situação em que o relacionamento entre as camadas é perfeito, mas o relacionamento entre as camadas internas é caótico.
A oitava etapa é padronizar o mecanismo de comunicação das camadas adjacentes. Na arquitetura em camadas, o mecanismo de comunicação comumente usado é o modelo push. Quando a camada J chama a camada J-1, todas as informações necessárias são transmitidas junto com a chamada de serviço .
O nono passo é desacoplar as camadas adjacentes.Em geral, em uma arquitetura em camadas, a camada superior conhece a camada inferior, mas a camada inferior não conhece a identidade da camada superior, formando assim um acoplamento unidirecional.
Colaboração entre camadas
Na cognição inerente a todos, a arquitetura em camadas é passada de cima para baixo. Da perspectiva do nível de abstração, quanto mais alto o nível de abstração, mais geral e público, mais distante esse nível é isolado do negócio específico. Esse nível é o que costumamos chamar de camada da plataforma ou chamador do framework.
De cima para baixo requer que a camada superior dependa da camada inferior, o que entra em conflito com o Princípio de Inversão de Dependência (DIP). O Princípio de Inversão de Dependência requer que módulos de alto nível não dependam de módulos de baixo nível, ambos devem depender de abstrações. Esse princípio me deu um lembrete claro de que quem estipulou que na arquitetura de cima para baixo, as dependências devem ser passadas na direção de cima para baixo, o que é um entendimento errado. A essência subjacente do Princípio de Inversão de Dependência é que dependemos de elementos imutáveis ou estáveis (classes, módulos ou camadas). Essa é a segunda frase do princípio: abstrações não devem depender de detalhes, e detalhes devem depender de abstrações.
O Princípio de Inversão de Dependência é uma manifestação do princípio do "design orientado à interface", ou seja, "programar para a interface, não para a implementação". O módulo de alto nível não sabe nada sobre a implementação do módulo de baixo nível e os benefícios são:
- A implementação detalhada dos módulos de baixo nível pode ser alterada independentemente para evitar alterações que afetem os módulos de alto nível
- Tanto os módulos de alto nível quanto os de baixo nível podem ser compilados independentemente um do outro, obtendo assim desenvolvimento e compilação independentes
- Para módulos de alto nível, a implementação de módulos de baixo nível é substituível
Se tanto o nível alto quanto o nível baixo dependem da abstração, haverá um problema agora, como passar a implementação específica da camada inferior para a camada de alto nível? Como o nível alto isola a dependência da implementação concreta através do "ponto ortogonal" dos dois, ou seja, a interface abstrata, então a dependência da implementação concreta é transferida para o exterior, e a implementação concreta será determinada pelo chamador externo. O chamador passará a implementação específica subjacente para o nível superior ao chamar o código. O guru do desenvolvimento de software Martin Fowler chama esse mecanismo de "injeção de dependência".
Portanto, para aliviar bem a dependência de alto nível na camada inferior, precisamos combinar inversão de dependência e injeção de dependência para melhor entendê-las.
Além disso, a transferência de informações entre as camadas não é necessariamente de cima para baixo, mas também pode ser de baixo para cima. Por exemplo, o mecanismo de notificação no sistema Android. Quando o sistema Android recebe a mensagem, o sistema Android notifica o módulo de negócios da camada superior da mensagem. Se a entrega da mensagem de cima para baixo for descrita como "solicitação" (ou chamada)", então a mensagem de baixo para cima pode ser descrita como "notificação". Pensando na "notificação" de outro ângulo, esta é realmente a comunicação entre o camada inferior e a camada inferior. Observação, o estado da camada inferior muda e a alteração da camada inferior é passada para a camada superior através do mecanismo de observação. A camada superior consome a mensagem passada para a camada inferior. Este modo é frequentemente chamado de modo observador.
Seja para realizar a "solicitação (ou chamada)" da camada superior para a camada inferior através do princípio de injeção de dependência e inversão de dependência, ou para realizar a "notificação" da camada inferior para a camada superior através do modo observador . Isso subverteu nossa compreensão inerente da dependência de alto nível do baixo nível em nosso pensamento.
Agora temos uma compreensão mais clara da assistência entre camadas, então devemos enfrentar o relacionamento colaborativo entre as camadas na arquitetura durante o desenvolvimento, quebrar o pensamento inerente de dependência de alto nível em baixo nível e explorar a perspectiva da dissociação (ou reduzindo o acoplamento) Possíveis relacionamentos colaborativos entre as camadas.
Além disso, também precisamos determinar os princípios (ou restrições) de arquitetura em camadas, como permitir ou não chamadas entre camadas, ou seja, cada camada pode usar os serviços de todas as camadas inferiores a ela, não apenas das camadas inferiores adjacentes. Este é o chamado "sistema de camadas soltas (Sistema de camadas relaxadas)".
Paradigma Hierárquico Clássico
O paradigma clássico em camadas inclui principalmente a arquitetura clássica de três camadas, a arquitetura Ali de quatro camadas e a arquitetura em camadas orientada ao domínio DDD.
Arquitetura clássica de três camadas
A arquitetura clássica de três camadas divide os módulos funcionais do sistema em camada de apresentação (UI), camada lógica de negócios (BLL) e camada de acesso a dados (DAL) de acordo com suas funções. A arquitetura de três camadas é mostrada na Figura 3. A interface do usuário da camada de apresentação está localizada na parte superior da arquitetura de três camadas, que realiza a interação direta entre o sistema e o usuário e o processamento de eventos de mensagem; a camada de lógica de negócios BLL, que realiza processamento e transmissão de dados, e a interface É conectada com a camada de acesso a dados para reproduzir um link entre o passado e o futuro; a camada de acesso a dados DAL implementa operações como adicionar, excluir, modificar e consultar dados , e realimenta os resultados da operação para a camada de lógica de negócios BLL.
A arquitetura de quatro camadas do Alibaba
A arquitetura de quatro camadas do Alibaba adiciona uma camada de gerente à arquitetura original de três camadas e refina a arquitetura clássica original de três camadas em um diagrama de arquitetura, conforme mostrado na Figura 4
- Camada de interface aberta:
- A camada de interface aberta pode depender diretamente da camada de serviço ou da camada WEB;
- Dependendo da camada de serviço, o serviço pode ser encapsulado em RPC e exposto ao mundo externo;
- Baseando-se na camada WEB, o negócio pode ser encapsulado em HTTP e exposto ao mundo exterior.
- Camada de exibição do terminal:
- Responsável pela renderização e exibição do template em cada ponta;
- Atualmente, é principalmente renderização de velocidade, renderização JS, renderização JSP, exibição de terminal móvel, etc.;
- Camada web:
- Encaminhamento de controle de acesso, verificação de diversos parâmetros básicos, ou simples processamento de serviços não reutilizáveis, etc.;
- Camada de serviço:
- Principal responsável pela implementação de serviços específicos de lógica de negócios;
- Gerente geral da camada de processamento de negócios, as principais responsabilidades incluem:
- Encapsulamento de plataformas de terceiros: encapsulamento de componentes básicos comuns da camada de Serviço, como cache e processamento geral de middleware;
- Interaja com a camada DAO e reutilize vários DAOs
- Camada DAO:
- Camada de acesso a dados, interação de dados com MySQL, Oracle, Redis, etc.
Arquitetura em camadas DDD
A arquitetura em camadas orientada por domínio DDD, o design orientado por domínio é aprimorado ainda mais com base na arquitetura clássica de três camadas e uma camada de aplicativo é introduzida entre a camada superior da interface do usuário e a camada lógica de negócios. Após a introdução da camada de aplicação, os nomes de cada camada também foram ajustados de acordo com o conceito dirigido por domínio. Renomeie a camada de lógica de negócios para a camada de domínio e renomeie a camada de acesso a dados para a camada de infraestrutura (Infrastructure Layer).A Figura 5 mostra a arquitetura em camadas de Eric Evans em seu livro clássico "Domain Driven Design".
Resumir
Agora temos uma visão mais clara da arquitetura em camadas. Portanto, devemos quebrar o pensamento inerente de que falar sobre arquitetura em camadas deve ser a arquitetura clássica de três camadas ou a arquitetura de quatro camadas recomendada pelo design orientado a domínio e, em vez disso, considerar as camadas como uma manifestação do nível de abstração horizontal de separação de preocupações . Sendo esse o caso, o número de camadas de abstração na arquitetura não é fixo e até mesmo os nomes de cada camada podem não seguir os requisitos inerentes (clássicos) da arquitetura em camadas. A camada do sistema de design precisa ser determinada em combinação com os cenários de negócios específicos do sistema. Claro, também devemos reconhecer os prós e os contras de quantas camadas existem: muitas camadas introduzirão muita indireção e aumentarão despesas desnecessárias, e poucas camadas podem levar a uma separação insuficiente de interesses, resultando em uma estrutura de sistema irracional.
O paradigma de arquitetura em camadas é o paradigma de arquitetura mais comumente usado e facilmente abusado no desenvolvimento de software. Os desenvolvedores podem formular suas próprias camadas de acordo com as restrições e requisitos atuais de desenvolvimento de software, de modo a facilitar o desenvolvimento de software e a assistência ao desenvolvedor. Com base no paradigma de camadas, podemos modificar o código no módulo sem afetar outros módulos, que é a vantagem que a camada de software nos traz. É também uma característica de alta coesão e baixo acoplamento.