Clean Architecture - O inicio da Jornada
Tags: cleancode, beginners, node, architecture
Published: 2023-04-01 15:51:27



## Introdução  

No desenvolvimento de software, Clean Architecture é um padrão de arquitetura de software que enfatiza a separação de interesses e a independência das camadas. A Clean Arch tem sido cada vez mais adotada, pois ajuda a manter o código limpo e organizado, facilitando a manutenção e a evolução do software ao longo do tempo.

Aqui falaremos sobre como aplicar a Arquitetura Limpa no desenvolvimento de software e um pouco das ambiguidade que enfrentei


### O que é Clean Architecture?



A Clean Architecture é uma abordagem que busca separar as preocupações do negócio das preocupações tecnológicas. Ela propõe que o código seja dividido em camadas bem definidas, cada uma com uma responsabilidade clara e específica. 

 *Para quem já está familiarizado com o assunto, é perceptível a união entre os conceitos de clean arch e **S.O.L.I.D**.* 

***

#### Os Conceitos

 **Uncle Bob**( o criador de clean arch e SOLID) descreve em um artigo os tópicos que define se seu software será bem escrito se houver:
 
>- **Independent of Frameworks**. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints. 
>
>- **Testable**. The business rules can be tested without the UI, Database, Web Server, or any other external element.
>
>- **Independent of UI**. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
>
>- **Independent of Database**. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.
>
>- **Independent of any external agency**. In fact your business rules simply don’t know anything at all about the outside world.


--- 
 
#### As Camadas
 
 Tendo em vista dos conceitos primordiais que definem se de fato meu código segue essa arquitetura, vamos entender como consiste as quatro camadas principais da Clen Arch:

1.  Entidades: esta camada contém as entidades de negócios do sistema, que são independentes da implementação tecnológica. Essas entidades representam conceitos do mundo real, como clientes, pedidos, produtos, etc.
    
2.  Casos de uso: esta camada contém a lógica de negócios do sistema. Cada caso de uso é uma ação específica que o sistema deve realizar para atingir um objetivo de negócio.
    
3.  Adaptadores: esta camada contém as implementações concretas das interfaces definidas nas camadas de Entidades e Casos de Uso. Essa camada inclui adaptadores de banco de dados, adaptadores de API, adaptadores de UI, etc.
    
4.  Frameworks e drivers: esta camada contém o código que é específico da tecnologia utilizada, como bibliotecas de banco de dados, bibliotecas de UI, etc.
 
----

#### O Inicio da Jornada 

Eu comecei minha jornada no mundo dev com front-end, onde sempre gostei da interface,  aquilo que era visual, o famoso *client-side*. Como criar uma tela de login, LP era algo que dava para ser visto só jogando um "http://localhost:3000" no browser, segui por esse caminho, sem ao menos considerar a opção de estudo do back-end.

Com o passar do tempo, quis aprimorar mais os conhecimentos de desenvolvedor, e para onde eu ia, eu chegava em alguns conceitos, vídeos, cursos e artigos de back. Onde vi a necessidade de começar os estudos. 

Quando iniciei no back-end, quis fazer diferente do front, procurei aprender os conceitos, ler mais artigos e livros, entender o funcionamento de um sistema, antes mesmo de codar. O que para mim foi sensacional, porque desde o início dos estudos, pude ver a diferença entre um código com padrões de arquitetura, um código limpo, e o mais importante, saber quando usar. 

Às vezes quando aprendemos um framework ou biblioteca, já queremos sair colocando em todo projeto, não é errado, mas é bom entendermos qual a finalidade daquele sistema, para  que assim saibamos qual a melhor forma para solucionar o problema.

----

#### As Dificuldades Pelo Caminho... 

Depois de ter os conceitos, entender o funcionamento, comecei a codar, foi onde tive uma certa dificuldade no início. Porque eu vinha de uma programação funcional, e o desenvolvimento com alguns tipos de padrões arquiteturais, requer um conhecimento prévio em *Object-oriented programming (OOP)*.

Quando estive apto a começar de fato a codar, não foi mil maravilhas também, mesmo tendo os conceitos, tive uma dificuldade imensa para construir até mesmo um CRUD. Foi onde eu percebi que de fato, nós programadores aprendemos lendo, vendo vídeo, um artigo, até copiando um código rsrs, mas o que alavanca exponencialmente o nosso aprendizado são os erros, e isso é fato, de 100% dentro do que sei sobre back-end, 60% foram adquiridos por tentativa e erros, e código quebrando.

Hoje em dia a construção de um sistema com padrão clean arch é muito mais fácil de compreender, e sei qual o melhor cenário para se aplicar um padrão como esse. 

E na minha opinião, a melhor coisa desse padrão é a possibilidade de criação de um sistema completo, sem nem ao menos ter um framework ou DB, isso é o que me encanta no clean arch.


---

### Conclusão

A Arquitetura Limpa é uma abordagem que ajuda a manter o código limpo e organizado, facilitando a manutenção e a evolução do software ao longo do tempo. 

E na minha experiência com clean arch houve uma inversão da situação dos problemas e dificuldades, geralmente em um código sujo ou mal orquestrado os problemas começam a aparecer no final, quando já se tem uma complexidade, e dependendo da situação a fatoração desse sistema, pode levar o dobro de tempo ou ser quase impossível.

Agora seguindo alguns padrões como Clean arch no início para quem está começando as dificuldades batem na porta ali mesmo, mas isso é bom, esses erros nos dão bagagem e a compreensão do problema, assim quando vencermos as dificuldades iniciais, tudo flui melhor depois. Mas claro, não estou dizendo que nunca mais haverá erro no código, a questão é, a visualização do problema será mais fácil e qualquer mudança, não quebrará seu código. 

Se você está buscando uma abordagem de desenvolvimento mais organizada e escalável, vale a pena considerar a adoção da Clean Architecture em seus projetos.