Architecture propre - Trop de classes de cas d'utilisation

Je vais dans une architecture propre et j'élève mon niveau Android de MVC à MVP , en introduisant DI avec Dagger 2, Reactivity avec RxJava 2 et bien sûr Java 8.

Dans l'architecture propre MVP, il existe une couche entre les entités (dans les banques de données) et les présentateurs qui doivent y accéder. Cette couche est le "Cas d'utilisation" . Un cas d'utilisation est idéalement une interface, qui implémente UNE opération sur UNE entité.

Je sais aussi que Clear Architecture " crie ", au sens où ses projets sont vraiment très lisibles tant le nombre élevé de classes qu'ils contiennent.

Maintenant, dans mon projet, j'ai quelque chose comme 6 entités différentes , et bien sûr, chaque référentiel d'entités a au moins 4 méthodes (généralement obtenir, ajouter, supprimer, mettre à jour) pour y accéder .. donc, 6 * 4 = 24 .

Si j'ai compris jusqu'à présent l'architecture propre, j'aurai 24 UseCase.

C'est beaucoup de classes par rapport à seulement 6 contrôleurs dans MVC ..

Dois-je vraiment faire 24 cas d'utilisation?

J'apprécierai vraiment une clarification par quelqu'un qui l'a déjà utilisé avec succès.

Merci, Jack

— Jackie Degl'Innocenti
source

Pouvez-vous publier un lien vers une page qui décrit ces cas d'utilisation en détail, avec un exemple de code?

— Robert Harvey

J'ai beaucoup cherché sur Google , mais principalement: cet exemple d'application et l'article connexe: github.com/jshvarts/OfflineSampleApp ; ces articles: proandroiddev.com/… ; proandroiddev.com/… ; Cette conférence: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; Et ces articles aussi: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Aucun des exemples d'applications ou d'articles que vous avez cités ne semble avoir grand-chose à voir avec l'architecture propre. Cependant, ils parlent beaucoup de programmation réactive.

— Robert Harvey

L'exemple d'application est sûrement fait avec le paradigme de l'architecture propre .. Les autres articles principalement .. Que voulez-vous voir @RobertHarvey?

— Jackie Degl'Innocenti

Lisez ma réponse ci-dessous et répondez.

— Robert Harvey

Réponses:

Dois-je vraiment faire 24 cas d'utilisation?

Seulement si tout ce que vous écrivez est CRUD .

Reportez-vous au schéma ci-dessous:

Votre affirmation est que vous aurez six entités différentes et 4 méthodes (Créer, Lire, Mettre à jour et Supprimer) pour chaque entité. Mais cela n'est vrai que dans le cercle jaune au milieu du diagramme (la couche Entités). Il est inutile de créer 24 méthodes dans la couche Cas d'utilisation qui passent simplement par des appels CRUD à la couche Entités.

Un cas d'utilisation n'est pas «Ajouter un enregistrement client». Un cas d'utilisation ressemble plus à «vendre un article à un client» (qui implique des entités client, produit et inventaire) ou «imprimer une facture» (qui implique les mêmes entités, en plus de l'en-tête de facture et des éléments de ligne de facture). ).

Lorsque vous créez des cas d'utilisation, vous devez penser aux transactions commerciales et non aux méthodes CRUD.

Pour en savoir plus
Aggregate - un cluster d'objets de domaine qui peuvent être traités comme une seule unité

— Robert Harvey
source

Vous passez trop de temps à réfléchir aux modèles, aux pratiques et à l'architecture, et pas assez de temps à la conception de logiciels de base. Tout ce dont vous avez besoin, ce sont des méthodes qui incarnent les pratiques commerciales, comme je l'ai décrit dans ma réponse.

— Robert Harvey

Il ne s'agit pas de choisir une architecture. Mon opinion personnelle: les opérations CRUD nues doivent parler directement à la couche d'entité. Bien sûr, cela viole probablement l'architecture propre.

— Robert Harvey

Vous manquez un peu le point. L'architecture n'est qu'un moyen d'organiser le code. Vous résolvez les problèmes en écrivant du code, pas en luttant avec les architectures.

— Robert Harvey

Hé Robert, ce n'est pas si gentil que tu penses que je n'écris pas de code. Le sujet de ma réponse est sur l'architecture, et nous ne sommes pas sur SO. Sincèrement, je trouve vos derniers commentaires vraiment trompeurs et sourds. La question concerne UseCase dans Clean Arch., Pas l'écriture de code. Si vous essayez de communiquer quelque chose, veuillez mieux l'expliquer, car je manque le point de vos commentaires. À mon humble avis, il n'est pas possible d'éviter les considérations d'architecture lors du développement de logiciels, ou du moins, les bons développeurs ne se contentent pas d'écrire des tas de code. De plus j'ai posé une question bien précise dans mon commentaire, pouvez-vous répondre? Merci

— Jackie Degl'Innocenti

La solution au problème que vous avez posé (application hors ligne en premier) n'a pas vraiment grand-chose à voir avec l'architecture propre. Vous ne trouverez pas de solution à ce problème dans le diagramme Architecture propre.

— Robert Harvey

Vous avez raison si chaque opération CRUD est traduite en un seul UseCase. Mais un UseCase peut également consister en plusieurs opérations CRUD.

Un UseCase est un modèle séparé qui collecte des informations à partir de différentes sources de données et prépare la communication avec les récepteurs de données. Il peut y avoir plusieurs opérations CRUD impliquées.

Pensez donc à un UseCase où créer une facture pour un client ET créer également le client lui-même car il / elle n'existe pas dans le système. Vous avez un UseCase qui se traduit par au moins deux Create-Operations dans une transaction.

— oopexpert
source

Alors, quel modèle recommanderiez-vous pour l'exemple du CRUD avec de nombreuses entités?

— Jackie Degl'Innocenti

Mon opinion personnelle à ce sujet est la suivante: je n'ai aucun problème à avoir de nombreuses classes tant qu'elles ne violent pas le SRP (principe de responsabilité unique). Mais la plupart du temps, je redéfinirais les cas d'utilisation "créer une entité", "mettre à jour une entité", "supprimer une entité" et "mettre à jour une entité" en une simple "entité de gestion de type X". Souvent, vous fournissez une interface utilisateur unique pour gérer une entité. Mais c'est exactement ce que votre UseCase devrait définir: la façon de gérer une charge de travail bénéfique pour votre entreprise.

— oopexpert

Ok, donc, avoir un cas d'utilisation qui gère diverses opérations différentes ne semble pas violer SRP car il semble simplement "agréger" plusieurs méthodes (et flux) différents dans le même UseCase sans qu'aucun seul flux ne gère plus d'une responabilité. .. mais de cette façon, ne créons-nous pas simplement un contrôleur à la place d'un UseCase? .. idée .. Peut-être que le cas d'utilisation doit être simplement vu comme une couche, et cette couche doit simplement respecter SRP mais peut également implémenter de nombreuses méthodes. Je voudrais avoir une source ou un article à ce sujet

— Jackie Degl'Innocenti

Un cas d'utilisation EST un contrôleur. La seule différence est qu'un cas d'utilisation vient du point de vue commercial et qu'un contrôleur en est la vue technique. L'objectif d'un cas d'utilisation est de savoir ce qui génère la valeur commerciale. Un cas d'utilisation est donc une implémentation de contrôleur axée sur la valeur commerciale.

— oopexpert

D'accord, un contrôleur HTTP est un moyen de gérer les E / S, il peut également y avoir des commandes de console, des réactions aux événements, etc. Tous ces canaux d'E / S appellent le même cas d'utilisation. Un cas d'utilisation est un contrôleur pour la logique métier, il ne connaît pas les canaux d'E / S à partir desquels il a été appelé, mais il sait comment orchestrer les entités de domaine pour faire le travail.

— Dmitriy Lezhnev

Votre définition du cas d'utilisation est erronée, le cas d'utilisation est une classe implémentant une règle métier, il ne doit pas nécessairement s'agir d'une opération CRUD, il peut s'agir d'une opération complexe en plusieurs étapes

— Buckstabue
source

Votre phrase ne signifie pas une solution lorsque vous avez réellement besoin d'implémenter une large gamme d'opérations de type Crud, même votre considération peut trouver une relation avec le fait qu'un cas d'utilisation devrait observer un modèle dans lequel nous pourrions accéder à une opération complexe, même en plusieurs étapes.

— Jackie Degl'Innocenti