Principais Lições
1. A arquitetura de software visa minimizar recursos humanos e maximizar a produtividade
O objetivo da arquitetura de software é reduzir ao máximo os recursos humanos necessários para construir e manter o sistema requerido.
Decisões arquitetônicas são fundamentais. Uma boa arquitetura diminui o esforço necessário para desenvolver, implantar e manter sistemas de software. Ela permite que as equipes trabalhem de forma independente, minimiza o impacto das mudanças e possibilita que o sistema evolua ao longo do tempo.
Aspectos essenciais de uma boa arquitetura:
- Separação de responsabilidades
- Gestão de dependências
- Abstração dos detalhes de implementação
- Flexibilidade para acomodar mudanças futuras
Ao focar nesses pontos, os arquitetos criam sistemas mais fáceis de entender, modificar e ampliar, o que resulta em maior produtividade e redução de custos durante toda a vida útil do sistema.
2. A arquitetura limpa separa as regras de negócio dos detalhes externos
O centro da sua aplicação não é o banco de dados. Tampouco são os frameworks que você utiliza. O centro da sua aplicação são os casos de uso.
As regras de negócio são o núcleo. A arquitetura limpa organiza o código em círculos concêntricos, com as regras de negócio no centro e os detalhes de implementação nas camadas externas. Essa separação garante que a lógica principal permaneça imune a mudanças em fatores externos, como bancos de dados, interfaces de usuário ou frameworks.
Camadas-chave na arquitetura limpa:
- Entidades: regras de negócio corporativas
- Casos de Uso: regras específicas da aplicação
- Adaptadores de Interface: convertem dados entre casos de uso e agentes externos
- Frameworks e Drivers: ferramentas e tecnologias externas
Seguindo essa estrutura, os desenvolvedores criam sistemas que são:
- Mais flexíveis e adaptáveis a mudanças
- Mais fáceis de testar e manter
- Menos dependentes de tecnologias ou frameworks específicos
3. Os princípios SOLID orientam a criação de sistemas flexíveis e fáceis de manter
Os princípios SOLID indicam como organizar funções e estruturas de dados em classes, e como essas classes devem se relacionar.
SOLID aprimora a modularidade. Esses cinco princípios oferecem diretrizes para criar sistemas de software mais compreensíveis, flexíveis e fáceis de manter. Eles ajudam os desenvolvedores a projetar códigos resistentes a mudanças e simples de estender.
Os princípios SOLID são:
- Princípio da Responsabilidade Única: uma classe deve ter apenas um motivo para mudar
- Princípio Aberto-Fechado: entidades de software devem estar abertas para extensão, mas fechadas para modificação
- Princípio da Substituição de Liskov: objetos de uma superclasse devem poder ser substituídos por objetos de suas subclasses sem afetar a correção do programa
- Princípio da Segregação de Interfaces: muitas interfaces específicas para clientes são melhores do que uma interface geral
- Princípio da Inversão de Dependência: módulos de alto nível não devem depender de módulos de baixo nível; ambos devem depender de abstrações
Aplicando esses princípios, os desenvolvedores criam arquiteturas de software mais robustas e escaláveis, capazes de se adaptar a requisitos em constante mudança.
4. Componentes são os blocos construtores da arquitetura limpa
Componentes são as unidades de implantação. São as menores entidades que podem ser implantadas como parte de um sistema.
Design modular promove flexibilidade. Na arquitetura limpa, componentes são partes do sistema que podem ser desenvolvidas e implantadas de forma independente. Eles encapsulam funcionalidades relacionadas e possuem interfaces bem definidas, facilitando a manutenção e modificação do sistema.
Características essenciais de componentes bem projetados:
- Alta coesão: funcionalidades relacionadas agrupadas
- Baixo acoplamento: dependências mínimas entre componentes
- Interfaces claras: métodos bem definidos de interação
- Implantação independente: podem ser atualizados ou substituídos sem afetar outras partes do sistema
Organizando sistemas em componentes, os arquitetos conseguem:
- Facilitar o desenvolvimento paralelo por equipes distintas
- Tornar os testes e a depuração mais simples
- Permitir atualizações incrementais e melhorias contínuas
- Melhorar a escalabilidade e a manutenção geral do sistema
5. Limites definem e protegem a lógica central do negócio
Em cada limite arquitetônico, é comum encontrar o padrão Humble Object por perto.
Limites protegem o núcleo. Os limites arquitetônicos na arquitetura limpa separam diferentes áreas de preocupação, especialmente entre a lógica de negócio e os detalhes de implementação. Esses limites mantêm a independência das regras centrais frente a mudanças externas.
Aspectos importantes dos limites arquitetônicos:
- Uso de interfaces para definir interações entre camadas
- Inversão de dependência para garantir que as dependências apontem para dentro
- Objetos de transferência de dados para passar informações entre limites
- Objetos humildes para separar comportamentos testáveis de componentes difíceis de testar
Estabelecendo limites claros, os arquitetos conseguem:
- Minimizar o impacto de mudanças em sistemas ou tecnologias externas
- Facilitar o teste da lógica central do negócio
- Permitir a substituição de detalhes de implementação sem afetar o núcleo do sistema
- Melhorar a flexibilidade e adaptabilidade geral do sistema
6. A arquitetura limpa facilita o desenvolvimento orientado a testes e a implantação independente
Uma boa arquitetura torna o sistema fácil de modificar, em todas as formas necessárias, mantendo as opções abertas.
Testabilidade e flexibilidade são essenciais. A arquitetura limpa promove práticas que tornam os sistemas mais fáceis de testar e implantar de forma independente. Ao separar responsabilidades e gerenciar dependências, fica mais simples escrever testes unitários para a lógica central e implantar componentes distintos separadamente.
Benefícios da arquitetura limpa para testes e implantação:
- Regras centrais podem ser testadas sem interface, banco de dados ou dependências externas
- Componentes diferentes podem ser implantados de forma independente, facilitando atualizações
- Mudanças em uma área têm impacto mínimo nas demais
- Novas funcionalidades podem ser adicionadas com menor risco de quebrar o que já existe
Essas características resultam em:
- Ciclos de desenvolvimento mais rápidos
- Menor risco nas implantações
- Maior confiabilidade do sistema
- Flexibilidade para adotar novas tecnologias ou modificar as existentes
7. Frameworks e bancos de dados são detalhes de implementação, não elementos arquitetônicos
Frameworks são ferramentas para serem usadas, não arquiteturas às quais se deve conformar.
A lógica central deve ser independente de frameworks. A arquitetura limpa trata frameworks e bancos de dados como detalhes externos que não devem influenciar a lógica principal do negócio. Essa abordagem permite maior flexibilidade para alterar ou atualizar esses elementos sem afetar a funcionalidade central.
Princípios para lidar com frameworks e bancos de dados:
- Tratá-los como plugins da lógica central
- Usar inversão de dependência para manter a lógica central independente
- Criar abstrações para operações de banco de dados
- Adiar decisões sobre frameworks e bancos de dados o máximo possível
Vantagens dessa abordagem:
- Facilidade para trocar ou atualizar frameworks e bancos de dados
- Estabilidade da lógica central apesar de mudanças externas
- Redução do aprisionamento a fornecedores
- Melhor testabilidade dos componentes centrais do sistema
8. A web é apenas mais um mecanismo de entrega na arquitetura limpa
A web é um mecanismo de entrega, e a arquitetura da sua aplicação deve tratá-la como tal.
A lógica de negócio é independente do meio de entrega. Na arquitetura limpa, a web é vista como um detalhe externo, assim como bancos de dados ou frameworks. Essa visão permite que a lógica central permaneça independente do mecanismo específico de entrega, seja uma aplicação web, desktop ou API.
Considerações para aplicações web na arquitetura limpa:
- Separar o código específico da web da lógica central
- Usar adaptadores de interface para converter entre formatos web e estruturas internas
- Tratar frameworks web como plugins do sistema central
- Projetar casos de uso independentes de preocupações específicas da web
Benefícios dessa abordagem:
- Facilidade para adaptar o sistema a diferentes mecanismos de entrega
- Reutilização da lógica central em múltiplas plataformas
- Testes simplificados das regras de negócio sem dependências web
- Maior flexibilidade para mudar ou atualizar tecnologias web
9. A arquitetura limpa para sistemas embarcados separa preocupações de hardware da lógica de negócio
Embora o software não se desgaste, pode ser destruído internamente por dependências não gerenciadas em hardware.
Independência do hardware é fundamental. A arquitetura limpa aplicada a sistemas embarcados separa as preocupações específicas de hardware da lógica central do negócio. Essa separação facilita atualizações de hardware e melhora a portabilidade do software.
Elementos-chave da arquitetura limpa embarcada:
- Camada de abstração de hardware (HAL) para isolar código específico de hardware
- Lógica de negócio independente de dispositivos
- Interfaces claras entre hardware e software
- Uso da inversão de dependência para gerenciar dependências de hardware
Vantagens dessa abordagem em sistemas embarcados:
- Facilidade para portar software para novas plataformas de hardware
- Testes simplificados da lógica central sem dependências de hardware
- Menor impacto de mudanças de hardware no sistema geral
- Melhor manutenção e longevidade do software embarcado
10. Microserviços e arquiteturas orientadas a serviços podem se beneficiar dos princípios da arquitetura limpa
A arquitetura de um sistema é definida por limites que separam elementos de software e impedem que os de um lado conheçam os do outro.
Princípios limpos valem para todas as escalas. Embora a arquitetura limpa seja frequentemente discutida em aplicações monolíticas, seus princípios podem ser aplicados com eficácia a microserviços e arquiteturas orientadas a serviços. Eles ajudam a manter a independência e testabilidade dos serviços individuais, gerenciando a complexidade dos sistemas distribuídos.
Aplicando arquitetura limpa a microserviços:
- Tratar cada microserviço como um contexto delimitado com sua própria arquitetura limpa
- Usar interfaces bem definidas para comunicação entre serviços
- Aplicar inversão de dependência entre serviços
- Manter a capacidade de implantação independente dos serviços
Benefícios da arquitetura limpa em microserviços:
- Modularidade e escalabilidade aprimoradas do sistema como um todo
- Facilidade para entender e manter serviços individuais
- Maior flexibilidade para evoluir e substituir serviços
- Redução do acoplamento entre serviços, resultando em sistemas mais robustos
Resumo das Resenhas
Clean Architecture: Um Guia do Artesão para Estrutura e Design de Software recebe opiniões divididas. Muitos elogiam o seu enfoque nos princípios SOLID e no desacoplamento, enquanto outros o consideram repetitivo e carente de exemplos práticos. Alguns leitores valorizam o contexto histórico e as anedotas apresentadas, ao passo que outros sentem que esses elementos desviam a atenção do conteúdo principal. De modo geral, o livro é visto como útil para compreender conceitos arquitetônicos em alto nível, mas as opiniões divergem quanto à sua utilidade para iniciantes em comparação com desenvolvedores experientes. Vários críticos apontam que o conteúdo poderia ter sido transmitido de forma mais concisa.
Outros Também Leram
Perguntas Frequentes
What's Clean Architecture about?
- Focus on Software Structure: Clean Architecture by Robert C. Martin emphasizes creating systems that are easy to develop, maintain, and deploy through effective software architecture.
- Timeless Principles: It outlines principles like SOLID, applicable across various programming paradigms, to guide developers in writing clean, maintainable code.
- Separation of Concerns: The book advocates for separating business rules from technical details, enhancing flexibility and adaptability in software design.
Why should I read Clean Architecture?
- Improve Software Design Skills: The book enhances understanding of software architecture, providing practical advice for real-world projects.
- Timeless Knowledge: Its principles are not tied to specific technologies, ensuring relevance throughout your career.
- Real-World Examples: Martin shares insights from his extensive experience, offering relatable examples and case studies to simplify complex concepts.
What are the key takeaways of Clean Architecture?
- Architecture is a Shape: Software architecture is defined by component division and communication, facilitating development and maintenance.
- Decouple Business Rules: Emphasizes separating business rules from technical details for easier changes and adaptations.
- Leave Options Open: Good architecture defers technical decisions, allowing flexibility to adapt to changing requirements.
What are the SOLID principles mentioned in Clean Architecture?
- Single Responsibility Principle (SRP): A class should have one reason to change, reducing complexity and easing maintenance.
- Open-Closed Principle (OCP): Software entities should be open for extension but closed for modification, minimizing bug risks.
- Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types without altering program correctness.
What is the Dependency Inversion Principle (DIP) in Clean Architecture?
- High-Level Modules: DIP states high-level modules should not depend on low-level modules; both should depend on abstractions.
- Abstractions Over Details: Depending on abstractions rather than concrete implementations makes systems easier to modify and extend.
- Use of Interfaces: Encourages using interfaces to define contracts between components, enhancing testing and maintenance.
How does Clean Architecture define good software architecture?
- Support for Use Cases: Good architecture must support intended use cases, making them clear and visible within the structure.
- Minimize Human Resources: It should minimize resources required for development, deployment, and maintenance through careful design.
- Leave Options Open: A well-designed architecture keeps options open for future changes, crucial for long-term success.
What is the significance of boundaries in Clean Architecture?
- Separation of Concerns: Boundaries separate system components, ensuring changes in one area don't adversely affect others.
- Control Over Dependencies: Managing dependencies across boundaries prevents disruptions, leading to a stable system.
- Facilitate Independent Development: Boundaries allow teams to work independently, enhancing productivity and reducing conflicts.
What is the "Screaming Architecture" concept in Clean Architecture?
- Architecture Reflects Intent: "Screaming Architecture" means the system's architecture should clearly communicate its purpose and functionality.
- Use Case Driven: Good architecture is driven by use cases, maintaining clarity and purpose throughout development.
- Avoid Framework Dependency: Architecture should be centered around business needs, not dictated by frameworks or tools.
How does Clean Architecture address testing?
- Testable Architectures: Emphasizes architectures that allow unit testing of business rules without external systems running.
- Humble Object Pattern: Separates hard-to-test code from testable code, focusing on logic without UI or framework complexities.
- Testing API: Suggests creating a testing API to bypass security constraints, enhancing the ability to test various scenarios.
How does Clean Architecture differentiate between the web and the architecture of a system?
- Web as a Delivery Mechanism: The web is viewed as a delivery mechanism, not a defining aspect of system architecture.
- Decoupling Delivery from Logic: Treating the web as a detail allows designing systems agnostic to delivery methods.
- Focus on Business Logic: Prioritizes business logic and use cases over web delivery specifics, ensuring core functionality remains intact.
What are the risks of using frameworks according to Clean Architecture?
- Tight Coupling: Frameworks can lead to tight coupling, making technology switches difficult.
- Overhead and Complexity: Heavy reliance on frameworks can introduce unnecessary complexity and hinder performance.
- Loss of Control: Over-reliance on frameworks can lead to a rigid system, making changes and adaptations challenging.
What are the best quotes from Clean Architecture and what do they mean?
- "Your architecture should tell readers about the system, not about the frameworks you used in your system.": Emphasizes architecture reflecting business domain and use cases, not technologies.
- "Frameworks are tools, not ways of life.": Reminds developers to maintain control over architecture, not be overly reliant on frameworks.
- "A good architecture makes it unnecessary to decide on Rails, or Spring, or Hibernate, or Tomcat, or MySQL, until much later in the project.": Highlights deferring technology decisions until architecture is established, promoting flexibility.
