Saubere Architektur - Zu viele Anwendungsfallklassen

Ich gehe in die saubere Architektur und hebe mein Android-Level von MVC auf MVP , indem ich DI mit Dolch 2, Reaktivität mit RxJava 2 und natürlich Java 8 einführe.

In der MVP Clean-Architektur gibt es eine Schicht zwischen den Entitäten (in Datenspeichern) und den Präsentatoren , die auf sie zugreifen sollen. Diese Ebene ist der "Anwendungsfall" . Ein Anwendungsfall ist idealerweise eine Schnittstelle, die EINE Operation für EINE Entität implementiert.

Ich weiß auch, dass Clear Architecture " schreit ", im Sinne seiner Projekte sind sie aufgrund der hohen Anzahl von Klassen in ihnen wirklich gut lesbar.

Jetzt habe ich in meinem Projekt ungefähr 6 verschiedene Entitäten , und natürlich verfügt jedes Entitäts-Repository über mindestens 4 Methoden (normalerweise abrufen, hinzufügen, löschen, aktualisieren), um darauf zuzugreifen. Also 6 * 4 = 24 .

Wenn ich bisher von Clean Architecture verstanden habe, habe ich 24 UseCase.

Dies sind viele Klassen im Vergleich zu nur 6 Controllern in MVC.

Muss ich wirklich 24 Anwendungsfälle erstellen?

Ich werde eine Klarstellung durch jemanden, der sie bereits mit Erfolg verwendet hat, sehr schätzen.

Danke, Jack

— Jackie Degl'Innocenti
quelle

Können Sie einen Link zu einer Seite veröffentlichen, auf der diese Anwendungsfälle mit Beispielcode ausführlich beschrieben werden?

— Robert Harvey

Ich habe viel gegoogelt, aber hauptsächlich: dieses App-Beispiel und den dazugehörigen Artikel: github.com/jshvarts/OfflineSampleApp ; diese Artikel: proandroiddev.com/… ; proandroiddev.com/… ; Dieser Vortrag: youtube.com/watch?v=TvsOsgd0--c&feature=youtu.be ; Und dieser Artikel auch: adityaladwa.wordpress.com/2016/10/25/…

— Jackie Degl'Innocenti

Keine der von Ihnen zitierten Beispiel-Apps oder Artikel scheint viel mit Clean Architecture zu tun zu haben. Sie sprechen jedoch viel über reaktive Programmierung.

— Robert Harvey

Die Beispiel-App wurde sicherlich mit dem Clean Architecture-Paradigma erstellt. Die anderen Artikel meistens. Was möchten Sie @RobertHarvey sehen?

— Jackie Degl'Innocenti

Lesen Sie meine Antwort unten und antworten Sie.

— Robert Harvey

Antworten:

Muss ich wirklich 24 Anwendungsfälle erstellen?

Nur wenn alles, was Sie schreiben, CRUD ist .

Siehe das folgende Diagramm:

Sie behaupten, dass Sie für jede Entität sechs verschiedene Entitäten und vier Methoden (Erstellen, Lesen, Aktualisieren und Löschen) haben. Dies gilt jedoch nur für den gelben Kreis in der Mitte des Diagramms (Ebene Entitäten). Es ist sinnlos, in der Ebene "Anwendungsfälle" 24 Methoden zu erstellen, die lediglich CRUD-Aufrufe an die Ebene "Entitäten" weiterleiten.

Ein Anwendungsfall ist nicht "Hinzufügen eines Kundendatensatzes". Ein Anwendungsfall entspricht eher "Verkauf eines Artikels an einen Kunden" (an dem Kunden- , Produkt- und Inventareinheiten beteiligt sind) oder "Rechnung drucken" (an dem dieselben Einheiten beteiligt sind, zusätzlich zu Rechnungskopf und Rechnungsposten ).

Wenn Sie Anwendungsfälle erstellen, sollten Sie an Geschäftstransaktionen denken , nicht an CRUD-Methoden.

Weiterführende Literatur
Aggregat - Ein Cluster von Domänenobjekten, die als eine Einheit behandelt werden können

— Robert Harvey
quelle

Sie verbringen zu viel Zeit damit, über Muster, Praktiken und Architektur nachzudenken, und nicht genug Zeit damit, über das grundlegende Software-Design nachzudenken. Alles, was Sie brauchen, sind Methoden, die Geschäftspraktiken verkörpern, wie ich in meiner Antwort beschrieben habe.

— Robert Harvey

Es geht nicht darum, eine Architektur zu wählen. Meine persönliche Meinung: Nackte CRUD-Operationen sollten direkt mit der Entitätsschicht sprechen. Dies verstößt natürlich wahrscheinlich gegen Clean Architecture.

— Robert Harvey

Du verpasst irgendwie den Punkt. Architektur ist nur ein Mittel, um Code zu organisieren. Sie lösen Probleme, indem Sie Code schreiben und nicht mit Architekturen ringen.

— Robert Harvey

Hey Robert, es ist nicht so schön, dass du annimmst, dass ich keinen Code schreibe. Das Thema meiner Antwort ist Architektur, und wir sind nicht auf SO. Mit freundlichen Grüßen Ich finde Ihre letzten Kommentare wirklich irreführend und taub. Die Frage bezieht sich auf UseCase in Clean Arch. Und nicht auf das Schreiben von Code. Wenn Sie versuchen, etwas zu kommunizieren, erklären Sie es bitte besser, da mir der Sinn Ihrer Kommentare fehlt. IMHO ist es nicht möglich, Architekturüberlegungen bei der Entwicklung von Software zu vermeiden, oder zumindest schreiben gute Entwickler nicht nur eine Menge Code. Außerdem habe ich in meinem Kommentar eine wirklich spezifische Frage gestellt. Können Sie diese beantworten? Danke

— Jackie Degl'Innocenti

Die Lösung des von Ihnen gestellten Problems (App zuerst offline) hat nicht wirklich viel mit Clean Architecture zu tun. Im Clean Architecture-Diagramm finden Sie keine Lösung für dieses Problem.

— Robert Harvey

Sie haben Recht, wenn jede CRUD-Operation in einem UseCase übersetzt wird. Ein UseCase kann aber auch aus mehreren CRUD-Operationen bestehen.

Ein UseCase ist ein getrenntes Modell, das Informationen aus verschiedenen Datenquellen sammelt und die Kommunikation mit Datensenken vorbereitet. Es können mehrere CRUD-Operationen beteiligt sein.

Stellen Sie sich also einen UseCase vor, in dem eine Rechnung für einen Kunden erstellt UND auch der Kunde selbst erstellt wird, weil er nicht im System vorhanden ist. Sie haben einen UseCase, der zu mindestens zwei Create-Operations in einer Transaktion führt.

— oopexpert
quelle

Welches Muster würden Sie für das Beispiel der CRUD mit vielen Entitäten empfehlen?

— Jackie Degl'Innocenti

Meine persönliche Meinung dazu lautet: Ich habe kein Problem damit, viele Klassen zu haben, solange sie nicht gegen SRP (Single Responsibility Principle) verstoßen. Aber die meiste Zeit definierte ich die Usecases "eine Entität erstellen", "eine Entität aktualisieren", "eine Entität löschen" und "eine Entität aktualisieren" zu einer einfachen "Entität vom Typ X verwalten" neu. Oft stellen Sie eine einzige Benutzeroberfläche zur Verfügung, um eine Entität zu verwalten. Aber genau das sollte Ihr UseCase definieren: Der Weg, um eine vorteilhafte Arbeitsbelastung für Ihr Unternehmen zu bewältigen.

— oopexpert

Ok, ein Anwendungsfall, der verschiedene Vorgänge verwaltet, scheint nicht gegen SRP zu verstoßen, da er nur mehr verschiedene Methoden (und Flows) in demselben UseCase "aggregiert", ohne dass ein einzelner Flow mehr als eine Verantwortung übernimmt. .. aber auf diese Weise erstellen wir nicht einfach einen Controller anstelle eines UseCase? .. Idee .. Vielleicht muss der Anwendungsfall einfach als Ebene gesehen werden, und diese Ebene muss nur SRP respektieren, kann aber auch viele Methoden implementieren. Ich hätte gerne eine Quelle oder einen Artikel darüber

— Jackie Degl'Innocenti

Ein Usecase ist ein Controller. Der einzige Unterschied besteht darin, dass ein Anwendungsfall aus geschäftlicher Sicht stammt und ein Controller die technische Sicht darauf ist. Der Fokus eines Anwendungsfalls liegt darauf, was den Geschäftswert generiert. Ein Anwendungsfall ist also eine geschäftswertgesteuerte Controller-Implementierung.

— oopexpert

Stimmen Sie zu, ein HTTP-Controller ist eine Möglichkeit, E / A zu verwalten. Es kann auch Konsolenbefehle, Ereignisreaktionen usw. geben. Alle diese E / A-Kanäle rufen denselben Anwendungsfall auf. Ein Anwendungsfall ist ein Controller für Geschäftslogik. Er kennt die E / A-Kanäle, von denen er aufgerufen wurde, nicht, weiß jedoch, wie Domänenentitäten für die Ausführung des Auftrags orchestriert werden.

— Dmitriy Lezhnev

Ihre Definition des Anwendungsfalls ist falsch. Der Anwendungsfall ist eine Klasse, die eine Geschäftsregel implementiert. Es muss keine CRUD-Operation sein. Es kann sich um eine komplexe mehrstufige Operation handeln

— Buckstabue
quelle

Ihr Satz bedeutet keine Lösung, wenn Sie tatsächlich eine breite Palette von Crud-ähnlichen Operationen implementieren müssen. Selbst Ihre Überlegung könnte einen Zusammenhang mit der Tatsache finden, dass ein Anwendungsfall ein Muster beobachten sollte, in dem wir auf eine komplexe Operation zugreifen können. sogar mehrstufig.

— Jackie Degl'Innocenti