Este será um relato sobre a impressão de um livro, e também serão discutidos alguns conceitos e conhecimentos que, graças a este livro, foram aprendidos.
Arquitetura
Você consegue, ao ler esta publicação, dar uma resposta clara à pergunta: o que é arquitetura? O que é arquitetura no contexto de programação e design? Qual o seu papel? Há muitas incertezas nesse termo. Parece claro, mas de alguma forma abstrato, sem precisão. Martin acredita, e eu concordo, que um aplicativo tem duas componentes:
- Comportamento (behavior) — as funções e tarefas que o programa (componente, serviço) realiza.
- Arquitetura — este termo diz respeito principalmente à mudança da aplicação.
Mas mesmo que o aplicativo execute muito bem a tarefa que deve, isso não significa que ele tenha uma boa arquitetura. Arquitetura não é sobre o comportamento do aplicativo. Arquitetura é sobre a facilidade de mudança, é sobre a facilidade de implantação, é sobre a independência do desenvolvimento. Arquitetura é sobre a velocidade com que um novo membro da equipe compreende o projeto.
E é assim que se constrói essa arquitetura, como evitar a dor de cabeça ao lidar com pequenas mudanças de requisitos por parte do PM ou do stakeholder: é sobre isso que o livro fala.
Sobre os autores
Antes de falar qualquer coisa sobre este livro, quero dizer um pouco sobre mim.
Atualmente sou um Strong Junior Developer, especializado no desenvolvimento de serviços usando ASP .NET CORE.
Já trabalho há um ano em uma 'galeria', e parece que estou lidando com isso aos poucos.
Eu já li este livro duas vezes e recomendo sua leitura para todos:
- desenvolvedores de sistemas embarcados;
- profissionais de front-end;
- profissionais de back-end;
- e até mesmo devops.
Em resumo, para todos que estão de alguma forma relacionados ao desenvolvimento de software, me refiro ao desenvolvimento direto de vários produtos; SAs e PMs não estão incluídos (embora também seria útil entender por que um dev pode levar o dobro do tempo em uma tarefa), eu recomendo a leitura deste livro.
E agora tentarei argumentar por que penso assim.
Um pouco sobre o autor deste livro (porque, para mim, a autoridade do autor tem um grande peso). Acredito que você vai me entender, mesmo que isso nem sempre esteja correto, mas quando uma pessoa respeitada na área diz algo, você tende a ter muito mais confiança no que foi dito. Por exemplo, eu acho que você acreditaria mais no diagnóstico dado por um médico do que em algo dito por uma pessoa aleatória (que apenas pesquisou os sintomas).
Robert Martin — também conhecido como Uncle Bob (Tio Bob) — trabalha na área da programação, em diferentes sistemas (de serviços web a sistemas embarcados), desde 1970. Ele é um consultor técnico e arquiteto, escreveu para várias revistas técnicas, é um programador muito experiente e uma das pessoas que desempenhou um papel chave na criação dos famosos princípios SOLID (pode-se dizer que ele é o criador). Também gostaria de adicionar que este livro foi recomendado por meu líder de equipe, que possui mais de 15 anos de experiência.
Sobre o livro
Dependências
Antes de ler o livro, li muitos artigos no mesmo Habr, onde aparecia a palavra "dependência". O que é isso, quem depende de quem, o que exatamente significa "depender", e como uma classe pode depender de outra?
E assim, ao longo da leitura do livro, eu assimilei dois pontos:
Dependência é um termo que significa que uma classe (componente, serviço) conhece outra classe (componente, serviço), e esse conhecimento no nível do código é determinado (agora os programadores de Java, C# e C entenderão) por uma importação específica do namespace. Em outras palavras: você tem a classe A com o namespace Default.Classes e a classe B com Another.Classes. Então, se no código fonte da classe A aparecer "using Another.Classes;" — isso significa que a classe A depende da classe B.
Para entender no diagrama onde está a classe dependente e onde não está — observe a direção da seta: em 1) a seta apontará da classe A na direção da classe B. Isso significa que a classe B é mais independente do que a classe A. E alterações na classe A não causarão nenhum "dano" à classe B.
SOLID
Uma das principais razões que me levaram a ler este livro foi a explicação dos princípios SOLID a partir da fonte original, pois o tio Rob desenvolveu esses princípios e pode-se dizer que, graças a ele, ouvimos esse nome — SOLID.
Para aqueles que não estão por dentro — esses princípios dizem e recomendam projetar seus aplicativos de acordo com 5 regras:
S — SRP (Princípio da responsabilidade única)
O — OCP (Princípio do fechado-aberto)
L — LSP (Princípio da substituição de Liskov)
I — ISP (Princípio da segregação de interface)
D — DIP (Princípio da 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 camadas (serviços).
Se você acha que o Princípio da responsabilidade única é sobre um classe ou módulo fazer apenas uma coisa — então você definitivamente precisa ler ao menos um capítulo sobre SOLID. Pois a definição apresentada acima é uma consequência, mas não a definição do próprio princípio.
Sobre a Inversão de Dependência
Quero chamar a atenção para a explicação do Princípio da Inversão de Dependência (o que é o D em SOLID). Ao longo da leitura do livro, percebi que não é apenas um princípio, mas também um mecanismo e uma ferramenta, através da qual você pode mudar a direção de suas dependências, e fazer, por exemplo, a lógica de negócios (DOMÍNIO) independente dos detalhes de implementação da camada de acesso a dados (DAL).
Embora o próprio princípio, junto com os outros em SOLID, signifique um pouco diferente do que o mecanismo, esse mecanismo é utilizado ao longo de todo o livro, e é um dos principais métodos para inverter e mudar a direção de suas dependências, que, por sinal, é utilizado em DDD.
Sobre a tomada de decisões arquitetônicas
Muito frequentemente, o livro mencionará o princípio da tomada de decisões arquitetônicas importantes: sobre qual banco de dados usar, qual framework usar, que biblioteca adicionar, o que usar como motor de busca, etc.
Assim, o autor acredita: você deve tomar O MÍNIMO possível desse tipo de decisões. Pois os requisitos podem mudar, as restrições de performance também, e o próprio comportamento tende a mudar. Durante o processo de desenvolvimento, uma decisão pode parecer menos eficaz do que outra, menos conveniente do que outra. E a força da sua arquitetura determinará quão rapidamente e sem dor você poderá substituir uma tecnologia por outra (sobre isso, aliás, fala o OCP).
Por exemplo, de repente, você decide usar MongoDb em vez de Postgresql, ou até mesmo arquivos, ou usar dados simulados, com os quais as operações serão realizadas na memória. E sob certas condições — isso pode obrigá-lo a reescrever quase toda a lógica.
Para evitar que tais situações ocorram, podemos utilizar alguns mecanismos que irão maximizar a distância entre a decisão e o seu tempo de aceitação. Um desses mecanismos é a abstração.
Referências ao DDD
DDD — Domain Driven Design — é uma abordagem para o desenvolvimento de serviços com lógica de negócios complexa e suscetível a mudanças, que visa o máximo entendimento entre os gestores do projeto (PMs, gerentes de vendas etc.) e os membros da equipe. Ou seja, para que todos os membros do projeto tenham uma linguagem ubíqua e possam entender uns aos outros, e que todos pensem em um mesmo domínio com as mesmas regras de negócios.
Se você é um defensor do DDD, ou quer se tornar um, ou se não entende muito sobre isso, mas deseja entender — o livro é leitura obrigatória, especialmente a segunda parte.
Aqui o autor explica a existência da Regra de Dependência e por que, ao segui-la, você construirá a arquitetura correta do aplicativo. Por que as dependências devem seguir na direção dos componentes de Alta Política, e por que. o domínio (O componente de Alta Política) deve ser independente da infraestrutura e como isso simplificará seu deployment e desenvolvimento.
Abstração
O Tio Rob também fala sobre como os detalhes de implementação podem prejudicar seu sistema e impedir que ele evolua sem dor no futuro.
Lembre-se!
BD é um detalhe de implementação.
Clientes (Web, Mobile, etc.) são detalhes de implementação.
Frameworks são detalhes de implementação.
É preciso se abstrair ao máximo de tudo isso e não depender, utilizando a Inversão de Dependência descrita acima com interfaces e abstrações, a Regra de Dependência e outros mecanismos.
Métodos de construção de módulos
Esta seção me agradou muito, como desenvolvedor de serviços em ASP .NET CORE. Pois aqui são discutidas metodologias para construir uma arquitetura única de serviço a partir de componentes prontos.
Robert descreveu 4 possíveis esquemas para a separação de camadas.
Ele deixou claro por que o mecanismo da arquitetura de 3 camadas: UI (controladores), Serviços (Domínio), DAL (Banco de Dados) — é bastante ruim em comparação com outros. Eu não vi muitos projetos, mas em cada um, por exemplo, em microserviços, utiliza-se exatamente a arquitetura de três camadas.
Além disso, frequentemente se utiliza a arquitetura de um-componente-um-serviço. No geral, ambas são boas, mas têm muitas desvantagens, especialmente em comparação com como a arquitetura é construída usando DDD, principalmente em serviços críticos para mudança e complexos.
Em resumo, chegamos ao final desta revisão do livro. Eu realmente gostei do livro, não me arrependo da leitura, agradeço ao autor. A vocês, caros leitores, obrigado pela atenção, não sejam tão duros — esta publicação é baseada na impressão que tive do livro e no meu entusiasmo pessoal.
Fonte: habr.com
