DESMISTIFICANDO A ARQUITETURA LIMPA | CAMADA DE APLICAÇÃO
ฝัง
- เผยแพร่เมื่อ 10 ต.ค. 2024
- Nesse vídeo vamos para o segundo episódio da série onde descomplicamos a Arquitetura Limpa.
Dessa vez, vamos explorar a Camada de Aplicação conceituando-a a implementado o caso de uso de criação de tarefas do nosso sistema de geranciamento de tarefas.
👉 Playlist da série "Arquitetura Limpa"
• DESMISTIFICANDO A ARQU...
🌎 Me siga nas redes e comunidades
dev.to/giraldidev
/ leogiraldimg
github.com/leo...
Eu trabalho como analista de sistemas e desenvolvo uma aplicação de chat integrada ao whatsapp Business, já peguei o projeto como legado, em uma arquitetura que era pra ser um MVC mas se tornou outra coisa que não dá pra definir cheio de acoplamento entre os serviços. Depois dessa experiência passei a estudar bastante sobre arquitetura limpa. Mas uma coisa que eu ainda não entendi muito bem seria como seria a melhor forma de evitar acoplamento no código.
A resposta é simples: dependa de interfaces e não de implementações concretas. O lado direita da figura clássica já mostra um pouco disso (In/Output Ports, que vem do Hexagonal).
Uma boa forma de responder a isso é seguir o SOLID e isso que falei acima é a letra D e para chegar nela você precisa passar pelas letras anteriores. Porém, todavia, entretanto, mas pode gerar muito código. Essa é a principal reclamação de quem é não é acostumado com Clean Arch. A dica é: desacople o que você julga necessário.
Já que tu citou o MVC. A ideia do MVC é estar na camada verde da Clean Arch (Controllers e Presenters/Views). Muito provavelmente, o seu problema é que a camada de persistência se "confunde" (na verdade, só mal implementada) com o domain model, já que está utilizando ORM (pessoal do DDD odeia rsrs). Ou seja, a camada em Azul tá no centro (Django, Rails ou qualquer outra porcaria similar sofre do mesmo problema). Então o primeiro passo pra você provavelmente deve tomar é abstrair a persistência. Em geral o pessoa usa o padrão repository (Favor. Não confundir, por exemplo, com o JPA do Java. O que falo é repository do DDD. Tem muita lib diz repository mas não é um repositório de fato. A ideia aqui é que não importa se é SQL, NoSQL, CSV, JSON ou qualquer outra porcaria). Pra isso não tem segredo: INTERFACE. Você pode ver isso no vídeo aos 17:48 (e como citei o JPA Repository, você pode fazer o mesmo no video. É só fazer um JPA Respository implementar o método save. Bem provavável que veremos isso no próximo vídeo de série).
Só pra condensar o que eu falei. Perceba que não tem persistência no vídeo (pelo menos não vi. Só deu uma pincelada). Não tem ORM ai no meio. Tá literalmente fazendo testes unitários de domain e use cases, o que é o recomendado pelo Uncle Bob no capitulo 21 na sessão "Arquiteturas Testáveis" (versão em Português, infelizmente).
@@caua.chagas.s é uma aplicação com o back em express, praticamente tudo usando pacotes e funções, sem o uso de classes.