it-swarm.com.de

Sollte sich die Geschäftslogik in der App oder im Backend befinden?

Ich habe vor kurzem begonnen, die saubere Architektur anzuwenden, während ich eine Android -Anwendung) entwickelt habe. Deshalb habe ich meine Anwendung in 4 verschiedene Teile unterteilt.

(enter image description here

Datenschicht

Enthält die Implementierung von Repositorys.

Geräteschicht

Enthält die Implementierung von Android verwandten Dingen wie AlarmManager, die sich nicht auf die Speicherung von Entitäten beziehen.

Domänenschicht

Hier werden Anwendungsfälle (Interaktoren) implementiert und Schnittstellen für Repositorys definiert.

Präsentation

UI-bezogene Dinge, Fragmente, Ansichtsmodelle, Aktivitäten.


Diese Anwendung ist nicht isoliert, sondern existiert in einem System mit einem Backend und einem Frontend (Web-App), in dem einige Benutzer die mobile App und andere die Web-App verwenden.

Entsprechend der sauberen Architektur sollte sich die Geschäftslogik nun in der Domänenschicht befinden. Aber in diesem Szenario habe ich das Gefühl, dass es nicht dorthin gehört. Nehmen wir ein Beispiel.

Angenommen, ein Benutzer kann MovieTickets in verschiedenen Kinos kaufen.
In diesem Szenario hätten wir einen Anwendungsfall namens PurchaseMovieTicket.

Nun ist die Frage. Wo soll die eigentliche Logik beim Kauf umgesetzt werden? Dies kann auf zwei Arten erfolgen.

Typ 1

Die meisten Beispiele für eine saubere Architektur auf Android betrachten das Repository nur als eine Möglichkeit, CRUD-Operationen durchzuführen, unabhängig davon, ob es sich in der Cloud oder im lokalen Speicher befindet (z. B. Android Room)). Dies würde bedeuten, dass der Anwendungsfall PurchaseMovieTicket Logik wie z.

  • Entfernen Sie Geld vom Benutzer
  • Fügen Sie dem Benutzer die Kinokarte hinzu
  • Rufen Sie update im Repository mit dem Benutzer als Parameter auf

Jetzt sind die Nachteile hier offensichtlich. Was ist, wenn das Backend andere Dinge im Zusammenhang mit dem Kauf von Kinokarten erledigen muss, vielleicht sogar mit anderen Systemen kommunizieren muss, dann müsste all dies auch in der App implementiert werden. Sie können fast sehen, wie dies nicht möglich ist.

Typ 2

Das Repository enthält eine Methode namens purchaseMovieTicket, die ein MovieTicket und einen Benutzer verwendet. Diese Methode würde die erforderliche Logik im Backend oder überall dort ausführen, wo sie implementiert ist.

Nachteil hier ist gut, der Anwendungsfall wird fast unnötig, weil er nur den Aufruf vom Ansichtsmodell an das Repository weiterleitet. Und es gibt keine Geschäftslogik, über die man sprechen könnte.

Frage

  • Welcher Typ eignet sich am besten für dieses System? Warum?
  • Ist es gut, die Geschäftslogik in das Backend zu stellen?
  • Wenn Sie sich für Implementierungstyp 2 entscheiden, verstößt das Repository gegen die Prinzipien der sauberen Architektur?
3
Ludvig W

Es sollte von Fall zu Fall sein, aber ich würde erwarten, dass der größte Teil der Logik in das Backend geht.

Ihr Interaktor enthält möglicherweise noch mehrere Methoden ("Ticketverfügbarkeit prüfen", "Ticket zum Warenkorb hinzufügen", "Checkout"), aber in einigen Fällen ist zu erwarten, dass die Implementierung sehr einfach ist.


Vielleicht möchten Sie Folgendes berücksichtigen:

  • Sicherheit. Jeder Code, dem Sie vertrauen müssen, wird im Backend implementiert. Angenommen, ein Hacker kann den Client-Code ändern, um das zu tun, was er will. Was passiert in Ihrem Beispiel vom Typ 1, wenn es so geändert wird, dass nur "Kinokarte zum Benutzer hinzufügen" und nicht "Geld vom Benutzer entfernen" aufgerufen wird?

  • Kommunikationskopplung. Wie Sie bereits erwähnt haben, bevorzugen Sie für alles, was mit anderen Systemen kommunizieren muss, das Backend, sodass der Client nur mit Ihrem Backend kommunizieren muss.

  • Reaktionsfähigkeit. Dinge auf der Client-Seite (abgesehen von umfangreichen Berechnungen) haben im Allgemeinen eine bessere Leistung für den Benutzer als die Kommunikation mit dem Backend. So etwas wie die Berechnung eines Gesamtkorbpreises könnte aus diesem Grund für den Kunden besser sein.

  • Vervielfältigung. Wenn Sie zwei Clients haben, muss die Logik im Client dupliziert werden. Bevorzugen Sie daher das Backend.

  • Datenort. Setzen Sie die Logik lieber mit den Daten ein, mit denen sie arbeitet. Wenn beispielsweise viele Daten aus der Backend-Datenbank berechnet werden müssen, aber nur ein kleines Ergebnis an den Benutzer gesendet wird, fügen Sie diese Logik in das Backend ein. Oder es könnte das Gegenteil zutreffen.

  • API . Platzieren Sie die Logik lieber so, dass sich die API des Backends zusammenhängend und konsistent anfühlt.

  • Rennbedingungen. Durch das Platzieren von Logik im Backend wird die Verwendung von Transaktionen und ähnlichen Techniken erheblich vereinfacht, wodurch das Risiko von Parallelitätsproblemen verringert wird.

  • Ressourcenanforderungen. Auf Mobilgeräten würde ich vorschlagen, dass umfangreiche Berechnungen im Backend durchgeführt werden sollten. Wenn dies eine Desktop-App ist, von der bekannt ist, dass sie nur auf anständigen Computern ausgeführt wird, ist es möglicherweise besser, das Client-Ende vorzuziehen, um die Serverlast zu verringern.

Beachten Sie, dass dies keine vollständige Liste ist.

7
just me

Die Definition der Begriffe "Frontend" und "Backend" ergibt sich aus der Trennung der Geschäftslogik (Backend) von der Benutzeroberfläche (Frontend). Ja, die Geschäftslogik sollte sich im Back-End befinden, unabhängig davon, ob es sich um einen Remote-Service oder einfach um eine andere Ebene in derselben Anwendung handelt.

Da Sie bereits über ein separates Back-End-System verfügen, sollten Sie Clean Architecture hauptsächlich auf dieses System anwenden, in dem die gesamte Geschäftslogik enthalten sein sollte. Die mobile App kann als Erweiterung der UI-Schicht des Back-End-Systems betrachtet werden und verfügt daher über keine eigene Geschäftslogik. Alle Anwendungsfälle und Repositorys befinden sich im Back-End, und die mobile App verwendet einfach ein Gateway, um mit dem Back-End zu kommunizieren.

4
casablanca

Ich bin ein DBA, kein Entwickler, also biete ich Ihnen eine Pro-DB-Perspektive.

Durch die Implementierung von Logik mithilfe einer Kombination aus gespeicherten Prozessen und tabellengesteuerten Werten in der Datenbank, die sowohl von der Web-App als auch von der mobilen App gemeinsam genutzt werden können, erhalten Sie Sicherheit, Leistung und Konsistenz.

Dies hat den zusätzlichen Vorteil, dass diese Änderung, wenn Sie eine Änderung vornehmen möchten, unabhängig von der Benutzeroberfläche sofort für alle Benutzer bereitgestellt wird.

Dies bedeutet auch, dass das Unternehmen Verhaltensänderungen vornehmen kann, ohne Software erneut bereitstellen zu müssen.

0