Esta será uma história sobre a impressão do livro, bem como alguns conceitos e conhecimentos que, graças a este livro, foram estudados
Arquitetura
Você pode, lendo esta publicação, dar uma resposta clara à pergunta, o que é arquitetura? O que é arquitetura no contexto de programação e design? Que papel ela desempenha? Existem muitas ambiguidades nesse termo. E tudo parece estar claro, mas de alguma forma abstrato e sem precisão. Martin acredita, e eu concordo com ele, que o aplicativo tem dois componentes:
- Comportamento (comportamento) - funções e tarefas que o programa (componente, serviço) executa.
- Arquitetura - este termo é mais sobre a alteração de aplicativos.
Mas mesmo que o aplicativo execute muito bem a tarefa que deve executar, isso não significa que ele tenha uma boa arquitetura. Arquitetura não é sobre comportamento do aplicativo. Arquitetura é sobre facilidade de mudança, arquitetura é sobre facilidade de implantação, arquitetura é sobre independência de desenvolvimento. Arquitetura diz respeito à velocidade com que o entendimento chega a uma nova pessoa em uma equipe
E aqui está como criar essa arquitetura, como se livrar de uma dor de cabeça com uma pequena alteração nos requisitos do PM ou de uma parte interessada: é isso que o livro dirá
Sobre autores
Antes de dizer qualquer coisa sobre este livro, quero falar um pouco sobre mim.
No momento, sou um Desenvolvedor Júnior Forte, especializado no desenvolvimento de serviços através do ASP .NET CORE.
Estou trabalhando em uma "galeria" há um ano e pareço estar fazendo um pouco
Eu já li este livro duas vezes e recomendo a todos que leiam:
- desenvolvedores de sistemas incorporados;
- alunos da frente;
- back endors;
- e até devopsam.
Em geral, para quem está de alguma forma conectado ao desenvolvimento do PP, quero dizer o desenvolvimento direto dos diferentes Saylov e PMs que não levamos em conta aqui (embora também seja útil saber por que uma empregada gasta duas vezes mais tempo em uma tarefa), aconselho você a ler este livro.
E agora vou tentar argumentar por que penso assim
Um pouco sobre o autor deste livro (porque para mim a autoridade do escritor desempenha um grande papel). Acho que você vai me entender, embora isso nem sempre seja correto, mas se uma pessoa autorizada na esfera lhe diz algo, você mostra muito mais confiança no que ele disse. Por exemplo, acho que você prefere acreditar no diagnóstico que o médico coloca a você do que em uma pessoa da multidão (pesquise os sintomas no Google)
Robert Martin - também conhecido como Ankle Bob (tio Bob) - trabalha no campo da programação em vários sistemas (de serviços da Web a sistemas de incorporação) desde 1970. Ele é consultor técnico e arquiteto, escreveu em várias revistas técnicas, é um programador muito experiente e uma pessoa que desempenhou um dos papéis principais na criação dos conhecidos princípios do SOLID (você pode dizer o criador). Além disso, quero acrescentar que meu líder de equipe com mais de 15 anos me aconselhou neste livro
Sobre o livro
Dependências
Antes de ler o livro, li muitos artigos sobre o mesmo Habré, onde apareceu uma palavra como "dependência". O que é, quem é dependente de quem, o que exatamente "depende" significa e como algumas classes podem depender de alguém?
E ao ler o livro, aprendi dois pontos:
Dependência é um termo que significa que alguma classe (componente, serviço) conhece alguma outra classe (componente, serviço), e esse conhecimento no nível do código é determinado (agora javistas, afiadores, as pessoas vão me entender) por uma certa importação de namespace . Em outras palavras: você tem uma classe A com um espaço para nome Default.Classes e uma classe B Another.Classes. Portanto, se o código da classe A aparecer usando Another.Classes; - isso significa que a classe A depende da classe B.
Para entender de acordo com o esquema em que a classe dependente está e onde não - observe a direção da seta: 1) a seta apontará da classe A na direção da classe B. Isso significa que a classe B é mais independente que a classe A. E as alterações na classe A , nenhum "dano" à classe B
SÓLIDO
Uma das principais razões para a leitura deste livro foi a explicação dos princípios do SOLID a partir da fonte original, porque o tio Rob desenvolveu esses princípios e podemos dizer que graças a ele ouvimos esse nome - SOLID.
Para quem não conhece, estes princípios são ditos e aconselhados a projetar suas aplicações de acordo com 5 regras:
S - SRP (princípio da responsabilidade única)
O - OCP (princípio aberto-fechado)
L - LSP (princípio de substituição de Liskov)
I - ISP (princípio de segregação de interface)
D - DIP (princípio de inversão de dependência)
Todos esses princípios podem ser aplicados no nível de classes e objetos, no nível de módulos e componentes e no nível de trilhos (serviços).
Se você acha que o princípio de responsabilidade única é sobre o fato de que a classe ou o módulo deve fazer apenas uma coisa, você definitivamente deve ler pelo menos o capítulo sobre Solid. Pois a definição dada acima é uma consequência, mas não a definição do próprio princípio
Sobre a inversão de dependência
Quero prestar atenção especial à explicação do Princípio da inversão de dependência (aquele que D é do SOLID). Ao ler o livro, entendi que isso não é apenas um princípio, é também um mecanismo e uma ferramenta com a qual você pode alterar a direção de suas dependências e tornar, por exemplo, lógica de negócios (DOMAIN) independente dos detalhes da implementação da camada de acesso a dados (DAL'a)
Embora o próprio princípio, juntamente com os outros no SOLID, signifique algo além do mecanismo, o mecanismo em si é usado ao longo do livro, e esse é um dos principais métodos para inverter e alterar a direção de suas dependências, que por sinal é usada com DDD.
Sobre a tomada de decisões arquiteturais
Muitas vezes, o livro menciona o princípio de tomar decisões arquitetônicas importantes: qual banco de dados usar, qual estrutura usar, qual biblioteca conectar, o que usar como mecanismo de pesquisa etc.
Portanto, o autor acredita: você deve tomar o mais rápido possível, esse tipo de decisão. Como os requisitos podem mudar, as restrições de desempenho também, o próprio componente comportamental tende a mudar. Durante o processo de desenvolvimento, alguma solução pode parecer menos eficaz que outra, menos conveniente que outra. E a força de sua arquitetura determinará com que rapidez e facilidade você pode substituir uma tecnologia por outra (a OCP diz isso a propósito).
Por exemplo, de repente, você decide usar o MongoDb em vez do Postgresql, ou arquivos em geral, ou usar dados simulados, cujas operações serão executadas na memória. E sob certas condições - isso pode possibilitar reescrever quase toda a lógica.
Para evitar tais situações, podemos usar alguns mecanismos que levarão o tempo de tomada de decisão o mais longe possível. Um desses mecanismos é a abstração.
Referências DDD
DDD - Domain Driven Design - uma abordagem para o desenvolvimento de serviços com lógica de negócios complexa, crítica para mudanças, que visa maximizar o entendimento de posições de gerenciamento de projetos (MPs, gerentes de vendas etc.), com remadores. Ou seja, haveria uma linguagem onipresente entre todos os membros do projeto, e todos poderiam entender o outro, e que todos pensariam no mesmo domínio com as mesmas regras de negócios.
Se você é um defensor do DDD, ou deseja ser um ou não entende alguma coisa sobre isso, mas quer entender, o livro é uma leitura obrigatória, especialmente a segunda parte do livro.
Aqui, o autor explica a existência da Regra de Dependência e por que, após ela, você criará a arquitetura correta do aplicativo. Por que as dependências devem seguir em relação aos componentes de alta política, por que o domínio (componente de alta política) deve ser independente da infraestrutura e como simplificará a implantação e o desenvolvimento para você
Abstração
O tio Rob também fala sobre como os detalhes da implementação podem prejudicar seu sistema e impedir que ele evolua sem problemas no futuro.
Lembre-se!
DB é um detalhe de implementação
Clientes (Web, celular, etc) - detalhes de implementação
Estruturas são um detalhe de implementação.
É necessário abstrair o máximo possível e não depender dele, usando a Inversão de Dependências descrita acima com interfaces e abstrações, Regra de Dependência e outros mecanismos
Métodos para construção de módulos
Gostei especialmente desta seção como desenvolvedor de serviços no ASP .NET CORE. Para isso, descreve as metodologias para a construção de uma arquitetura de serviço unificada a partir de componentes prontos.
Robert descreveu quatro possíveis esquemas de separação de camadas.
Ele deixou claro por que o mecanismo tão usado da arquitetura de três camadas: interface do usuário (controladores), serviços (domínio), DAL (banco de dados) - é ruim o suficiente em comparação com outros. Não vi muitos projetos, mas em cada um, por exemplo, microsserviço, no back-end, ele usa uma arquitetura de três camadas.
Além disso, muitas vezes, a arquitetura de um componente e um serviço é usada. Em geral, ambos são bons, mas há muitas desvantagens, em comparação, por exemplo, como a arquitetura é construída usando DDD, especialmente quando é crítico mudar, e serviços complexos.
Em geral, esta revisão do livro chegou ao fim. Gostei muito do livro em si, não me arrependo do que li, graças ao autor. Obrigado pela atenção, queridos leitores, não julguem rigorosamente - esta publicação é baseada na impressão do livro e no meu entusiasmo pessoal
UPDATE 1.0
Durante as discussões, pode-se entender que a troca de armazenamento SUDDEN e FÁCIL não será fácil, de um jeito ou de outro. Em alguns casos, mesmo com uma abstração e encapsulamento muito dolorosos e, ainda assim, de acesso à loja, é duvidoso o que tornará a situação pior, mas um pouco melhor, pelo menos devido à independência do componente variável do resto.