> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2021/w13-preliminary-assessment-for-architecture-selection.md).

# W13-Erste Bestandsaufnahme zur Architekturwahl

Diese Woche habe ich Architekturansätze einiger Geschäftsprojekte im größeren Frontend-Bereich untersucht, um die Architekturwahl für die Händlerplattform vorzubereiten. Bislang habe ich drei Kategorien gefunden.

Seitenbasierte Microfrontends auf Grundlage von Open-Source-Frameworks. Sie werden mit Frameworks wie qiankun und garage aufgebaut. Typische Projekte sind Anwendungen für die Managementseite, etwa CMM im Ecosystem-Bereich und die Zhuge-Plattform.

Komponentenbasierte Microfrontends auf EDC. Ein Beispiel ist MFC von Ecosystem Finance. Seine Stabilität und Nutzbarkeit wurden im Privatkunden-Co-Branding-Kartengeschäft teilweise bestätigt. Es entwickelt sich gerade zu einer Plattform für andere Teams. Die Kosten einer Anbindung und Umstellung müssen wir noch klären.

Mehrseitenarchitektur auf Node. Ein Beispiel ist CORPS aus dem Privatkunden-Anlagegeschäft. **Sie** löst die Aufteilung und Eigenständigkeit von Geschäftsabläufen. Bei der Händlerplattform liegt das Problem eher in horizontal gekoppelten Geschäftsbereichen. Die Optimierung vertikaler Abläufe ist weniger dringlich.

Angesichts knapper Personalressourcen und eines weiterlaufenden Geschäfts sollten wir die Kriterien in dieser Reihenfolge gewichten: Kosten, Stabilität, Performance. Kosten umfassen sowohl einen günstigen Wechsel bestehender Projekte als auch geringe Wartungs- und Verständnisaufwände im Team. Mit Stabilität meine ich hier die Stabilität der Architektur selbst. Sie sollte mindestens das heutige Niveau der Händlerplattform erreichen. Durch die eigenständige Verwaltung der einzelnen Teildienste dürfte zugleich die Stabilität der gesamten Projektiteration deutlich steigen. Performance bezeichnet die obere Leistungsgrenze der neuen Architektur. Hier halte ich Kompromisse für vertretbar. Zum einen sind die bestehenden Dienste noch nicht besonders schnell und bieten viel Verbesserungsspielraum. Zum anderen tolerieren B2B-Szenarien bei der Performance mehr als Privatkundenszenarien.