Olá! Estou estudando a Clean Architecture, mas umas coisas me chamaram atenção:
- No exemplo construído em aula, as implementações concretas dos repository, que estão na camada de "infra" (interface adapters) na nomenclatura do uncle bob, dependem diretamente do domínio (entities/Enterprise business rules) , tanto que dão import nas classes da package aluno. A dependência está no sentido correto da regra, porém Uncle bob é explícito e claro ao dizer ( tanto no livro, quanto no artigo em seu blog que apresentou a Clean Architecture, n subtítulo "What data crosses the boundaries.") que os dados que cruzam fronteiras (ou seja, de uma camada a outra) são no máximo estruturas de dados simples, nunca ENTIDADES. Em outras palavras, deveria ser retornado (no máximo) um DTO e não a classe que contém as regras da entidade em si. Correto?
- Foi argumentado sobre o porque o repository fica na camada domínio. No entanto, além de eu não estar convencido conceitualmente de que persistência não é um conceito da aplicação, isso faz com que a dependência, apesar de no sentido correto, pule uma camada (a infra dependa diretamente da entidade, pulando a camada de aplicação). Isto é permitido/desejável? Em outras palavras, a clean architecture é uma arquitetura em camadas relaxada ou estrita? Eu não encontrei isto claro no livro, mas tenho uma pista de que Uncle bob pensou a interface do repository na camada de use cases. Trecho do livro (cap 23, pag 217):
"Entre os interagentes dos casos de uso e o banco de dados ficam os gatewais do banco de dados. Esses gateways são interfaces polimórficas(...). Lembre-se que não permitimos a presença de SQL na camada de casos de uso; em vez disso usamos interfaces de gateways com métodos adequados. Esses gateways são implementados por classes na camada da base de dados"
