Arquitetura limpa - muitas classes de casos de uso

Estou entrando na arquitetura limpa e elevo meu nível Android do MVC para o MVP , introduzindo o DI com o Dagger 2, a reatividade com o RxJava 2 e, claro, o Java 8.

Na arquitetura limpa do MVP, há uma camada entre as entidades (nos datastores) e os apresentadores que devem acessá-los. Essa camada é o "Caso de Uso" . Um caso de uso é idealmente uma interface, que implementa UMA operação em UMA entidade.

Sei também que a Clear Architecture " está gritando ", no sentido de seus projetos serem realmente altamente legíveis como o alto número de classes neles.

Agora, no meu projeto, tenho algo como 6 entidades diferentes e, é claro, cada repositório de entidades possui pelo menos 4 métodos (geralmente obtém, adiciona, exclui, atualiza) para acessá-los. Então, 6 * 4 = 24 .

Se o que eu entendi até agora de Arquitetura Limpa, terei 24 UseCase.

São muitas classes se comparadas a apenas 6 controladores no MVC.

Eu realmente tenho que fazer 24 casos de uso?

Eu realmente aprecio um esclarecimento de alguém que já o usou com sucesso.

Obrigado Jack

— Jackie Degl'Innocenti
fonte

Você pode postar um link em uma página que descreve esses casos de uso em detalhes, com código de exemplo?

— Robert Harvey

Pesquisei bastante no Google, mas principalmente: este exemplo de aplicativo e artigo relacionado: github.com/jshvarts/OfflineSampleApp ; este artigo: proandroiddev.com/… ; proandroiddev.com/… ; Esta palestra: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; E este artigo também: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Nenhum dos aplicativos ou artigos de amostra que você citou parece ter muito a ver com a Arquitetura Limpa. No entanto, eles falam muito sobre programação reativa.

— Robert Harvey

O aplicativo de amostra é certamente feito com o paradigma da arquitetura limpa. Os outros artigos, principalmente .. O que você deseja ver @RobertHarvey?

— Jackie Degl'Innocenti

Leia minha resposta abaixo e responda.

— Robert Harvey

Respostas:

Eu realmente tenho que fazer 24 casos de uso?

Somente se tudo que você escreve for CRUD .

Consulte o diagrama abaixo:

Sua afirmação é que você terá seis entidades diferentes e quatro métodos (Criar, Ler, Atualizar e Excluir) para cada entidade. Mas isso só é verdade no círculo amarelo no meio do diagrama (a camada Entidades). Não faz sentido criar 24 métodos na camada Casos de Uso que simplesmente passam por chamadas CRUD para a camada Entidades.

Um caso de uso não é "Adicionar um registro de cliente". Um Caso de Uso é mais parecido com "Vender um item para um cliente" (que envolve entidades de Cliente, Produto e Inventário) ou "Imprimir uma fatura" (que envolve as mesmas entidades, além de Cabeçalho da Fatura e Itens de Linha da Fatura )

Ao criar Casos de Uso, você deve pensar em transações comerciais, não em métodos CRUD.

Leitura adicional
agregada - um cluster de objetos de domínio que podem ser tratados como uma única unidade

— Robert Harvey
fonte

Você está gastando muito tempo pensando em padrões, práticas e arquitetura e pouco tempo pensando em design de software básico. Tudo que você precisa são métodos que incorporem práticas de negócios, como descrevi na minha resposta.

— Robert Harvey

Não é uma questão de escolher uma arquitetura. Minha opinião pessoal: operações CRUD nuas devem falar diretamente com a camada de entidade. Obviamente, isso provavelmente viola a arquitetura limpa.

— Robert Harvey

Você está meio que perdendo o objetivo. A arquitetura é apenas um meio de organizar o código. Você resolve problemas escrevendo código, não lutando com arquiteturas.

— Robert Harvey

Ei, Robert, não é tão legal que você assuma que eu não escrevo código. O tópico da minha resposta é sobre arquitetura e não estamos no SO. Atenciosamente, acho seus últimos comentários realmente enganadores e surdos. A pergunta é sobre o UseCase no Clean Arch., Não escrevendo código. Se você está tentando comunicar algo, explique melhor, porque estou perdendo o objetivo de seus comentários. IMHO não é possível evitar a consideração da arquitetura ao desenvolver software, ou pelo menos, bons desenvolvedores não apenas escrevem um monte de código. Além disso, fiz uma pergunta realmente específica no meu comentário, você pode responder? Obrigado

— Jackie Degl'Innocenti

A solução para o problema que você colocou (aplicativo offline primeiro) realmente não tem muito a ver com a Arquitetura Limpa. Você não encontrará uma solução para esse problema no diagrama Clean Architecture.

— Robert Harvey

Você está certo se toda operação CRUD for traduzida em um UseCase. Mas um UseCase também pode consistir em várias operações CRUD.

Um UseCase é um modelo separado que reúne informações de diferentes fontes de dados e prepara a comunicação com os coletores de dados. Pode haver várias operações CRUD envolvidas.

Então, pense em um UseCase onde criar uma fatura para um cliente E criar também o próprio cliente, porque ele não existe no sistema. Você tem um UseCase que resulta em pelo menos duas operações de criação em uma transação.

— oopexpert
fonte

Então, qual padrão você recomendaria para o exemplo do CRUD com muitas entidades?

— Jackie Degl'Innocenti

Minha opinião pessoal é: não tenho problema em ter muitas classes, desde que não violem o SRP (princípio de responsabilidade única). Mas na maioria das vezes redefiniria os Usecases "criar uma entidade", "atualizar uma entidade", "excluir uma entidade" e "atualizar uma entidade" para uma simples "entidade gerenciadora do tipo X". Geralmente, você fornece uma única interface do usuário para gerenciar uma entidade. Mas é exatamente isso que seu UseCase deve definir: A maneira de lidar com uma carga de trabalho benéfica para os seus negócios.

— oopexpert

Ok, então, ter um Caso de Uso que gerencia várias operações diferentes não parece violar o SRP, pois parece "agregar" métodos (e fluxos) mais diferentes no mesmo UseCase, sem que nenhum fluxo único lide com mais de uma responsabilidade. .. mas dessa maneira não estamos apenas criando um controlador no lugar de um UseCase? .. idéia .. Talvez o Caso de Uso deva ser simplesmente visto como uma camada, e essa camada apenas precise respeitar o SRP, mas também pode implementar muitos métodos. Eu gostaria de ter uma fonte ou artigo sobre isso

— Jackie Degl'Innocenti

Um Usecase IS Um controlador. A única diferença é que um caso de usuário vem da perspectiva de negócios e um controlador é a visão técnica dele. O foco de um caso de uso é o que está gerando valor comercial. Portanto, um caso de usuário é uma implementação de controlador orientada por valor comercial.

— oopexpert

Concordo, um controlador HTTP é uma maneira de gerenciar E / S, também pode haver comandos de console, reações a eventos e assim por diante. Todos esses canais de E / S chamam o mesmo caso de usuário. Um caso de uso É um controlador para lógica de negócios, não sabe sobre os canais de E / S de onde foi chamado, mas sabe como orquestrar entidades de domínio para realizar o trabalho.

— Dmitriy Lezhnev 20/05/19

Sua definição de Caso de Uso está incorreta, Caso de Uso é uma classe que implementa uma regra de negócios, não precisa ser uma operação CRUD, pode ser uma operação complexa em várias etapas

— Buckstabue
fonte

Sua sentença não significa uma solução quando você realmente precisa implementar uma ampla variedade de operações semelhantes a Crud, mesmo sua consideração pode ter alguma relação com o fato de que um Caso de Uso deve observar um padrão no qual podemos acessar uma operação complexa, mesmo multi passo.

— Jackie Degl'Innocenti 14/03/19