Vermeidung der Duplizierung von Geschäftslogik über mehrere verschiedene Präsentationsebenen hinweg

Ich entwerfe derzeit die Architektur für ein Multi-Channel-Commerce-System, das mehrere verschiedene Frontend-Präsentationen haben wird, die auf Gerät und Kanal zugeschnitten sind (Benutzertyp und Standort). Die Herausforderung für mich besteht darin, sicherzustellen, dass wir die Core-Commerce-Plattform so entwickeln, dass Doppelungen in den Frontend-Präsentationsschichten vermieden werden.

Hier ist eine Auswahl der verschiedenen Frontend-Präsentationen, die wir unterstützen müssen:

• Traditionelle Desktop-basierte Website für Verbraucher
• Mobile optimierte Website für Verbraucher
• Native mobile Anwendungen (iOS / Android) für Verbraucher
• Customer Support Center-Website für Kundenbetreuer
• Instore-Kiosk-basierte Website für Verbraucher, die in gemauerten Lokalen einkaufen
• Andere (Microsites und andere mit verschiedenen Technologien wie Angular, PHP, .NET, etc)

Jetzt kenne ich die Best Practices für eine mehrschichtige Architektur (Präsentation, Business, Datenebenen) und gängige Designmuster, um Frontend-Herausforderungen innerhalb einer einzelnen App (wie MVC, Validatoren, Interceptors) zu adressieren. Keines dieser Prinzipien erklärt jedoch wie und wo , um Ihre präsentationsspezifische Geschäftslogik am besten zu kapseln, wenn Sie mit der Unterstützung konfrontiert werden mehrere Frontends.

Also, meine Frage ist Was sind einige gute Praktiken und Prinzipien, die bei der Entwicklung eines solchen Systems zu beachten sind, um sicherzustellen, dass jede Frontend-Anwendung nicht die Frontend-Geschäftslogik dupliziert?

Ich habe viele Anwendungen mit solchen Anforderungen in der Vergangenheit entwickelt, die verschiedene Ansätze verwenden ... einige davon haben recht gut funktioniert und einige, die nicht so gut funktionierten. Aber jedes Mal hatte ich das Gefühl, dass ich eine Lösung für ein gemeinsames Problem erfand und dass es einige Best Practices und Prinzipien geben muss, die es zu nutzen gilt.

Ein schnelles Beispiel für die spezifischen Herausforderungen, nach denen ich frage

Alle unsere Frontend-Anwendungen müssen die Möglichkeit unterstützen, ein neues Kundenkonto zu registrieren. Das Registrierungsformular wird Informationen wie E-Mail, Passwort und Kundenadressinformationen (Straße, Stadt, PLZ, etc.) aufnehmen. Wenn das Formular abgeschickt wird, werden bestimmte triviale und nicht-triviale Validierungen durchgeführt, bevor das Konto im System erstellt wird und eine Bestätigungs-E-Mail an den Benutzer gesendet wird. Zum Beispiel:

• Musterprüfregeln für E-Mail-Adressen
• Sicherstellen, dass die E-Mail-Adresse nicht im System vorhanden ist
• Regeln zur Kennwortkomplexität
• Adressvalidierung (über ein Drittanbieter-Adressvalidierungs- / Standardisierungssystem)

In den meisten Fällen müssen diese Validierungsregeln für alle Frontend-Systeme durchgesetzt werden, obwohl sich der Registrierungsfluss jedes Frontends leicht unterscheiden kann und möglicherweise nur eine Teilmenge der Felder enthält. Also, was sind einige gute Praktiken, um eine API zu den Frontends bereitzustellen, so dass jedes Frontend nicht die verschiedenen Schritte dupliziert, die notwendig sind, um die Registrierung richtig zu validieren und zu verarbeiten? Wenn wir beispielsweise die Regeln für die Kennwortkomplexität oder die Adressüberprüfungsregeln ändern möchten usw. - wie könnten wir das System am besten so gestalten, dass wir nicht alle verschiedenen Frontend-Anwendungen mit dieser neuen Validierungslogik ändern müssen.

Nur um klar zu sein, ich bin nicht besorgt darüber, wo Kerngeschäftslogik, die über alle Frontends (d. h. Kontoerstellungsdienste, Adressvalidierungsdienste, Account-Lookup-Dienste, usw.) geteilt wird. Diese Muster werden häufig in Blogs, Büchern und Foren diskutiert. Meine Fragen beziehen sich speziell auf die Geschäftslogik, die normalerweise eng mit der Präsentationsschicht verbunden ist. Einige Fragen, die mir immer wieder auffallen.

• Sollten wir eine Präsentationsserviceschicht bereitstellen, die alle Frontend-Operationen einschließlich Formularvalidierungen und Verarbeitung über Webdienste unterstützt? Oder sollte jedes Frontend seine Präsentationslogik besitzen, weil "keine zwei Frontends gleich sind"?
• Wenn wir eine Präsentationsdienstschicht erstellen , wie stellen wir Dienste bereit, die die feinen Unterschiede jedes Frontends berücksichtigen? Stellen wir verschiedene Dienste / Endpunkte für jedes dieser Frontends zur Verfügung oder stellen wir einfach verschiedene "Kontexte" zur Verfügung, die jedes Frontend beim Aufruf unserer Services passiert?
• Steuert diese Präsentationsdienstschicht die Fehlerbenachrichtigung und gibt die entsprechende kontextsensitive Nachricht an jedes Frontend zurück, oder sollten wir nur Fehlercodes zurückgeben und dem Frontend dies überlassen?
• usw.