Produktorientierte RefArch-Roadmap: ZMS-Architektur modernisieren (3–5-Jahresplan)

Einführung

ZMS entwickelt sich von einem projektgetriebenen PHP-Stack zu einer langfristigen, produktorientierten Plattform. Für mehrjährige Wartbarkeit, schnellere Auslieferung und klarere Ownership schlagen wir eine Referenzarchitektur (RefArch) vor, die Technologieentscheidungen, Laufzeit-Topologie und Integrationsmuster über alle Module hinweg standardisiert.

https://refarch.oss.muenchen.de/

https://github.com/it-at-m/refarchhttps://github.com/it-at-m/refarch-templates

Diese Roadmap verbindet Geschäftsergebnisse mit technischer Umsetzung: Kernfähigkeiten in einen gemeinsamen Spring-Boot-Backend-Dienst (zmsbackend) zusammenführen, API-Gateways für klare Eingangsgrenzen einführen, alle Frontends auf Vue.js modernisieren und EAI-Themen (Messaging, externe Datenflüsse) als eigene Dienste isolieren. Der Zielzustand reduziert kognitive Last, verbessert Sicherheit und Betrieb und ermöglicht Teams, Arbeit unabhängig zu skalieren ohne fragile Querkopplung.

Wichtige Treiber:

• Produktorientierung und Domain-Ownership
• Weniger Technologie-Schulden und konsistente Developer Experience
• Einheitliche UX über interne und bürgerorientierte Apps hinweg
• Stärkere Sicherheitsposition an Gateway-Grenzen
• Observability by default (Logs, Metriken, Traces, SLOs)
• Vorhersehbare Releases durch automatisierte Tests und CI/CD
• Klare Zuständigkeit (Kern vs. EAI-Integrationen)
• Langfristige Tragfähigkeit für 3–5 Jahre mit inkrementellen Migrationspfaden
• Wiederverwendbarkeit durch andere Städte und Behörden

Aktueller Abhängigkeitsgraph

zmscitizenview und refarch-gateway setzen auf zmscitizenapi auf, ziehen aber keine direkten Abhängigkeiten von dort. Ebenso sendet zmscitizenapi Anfragen an zmsapi, doch zmsapi ist keine direkte Abhängigkeit von zmscitizenapi.

%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
graph TD;
    %% Main ZMS module dependencies
    zmsapi --> zmsslim & zmsclient & zmsdldb & zmsdb & zmsentities;
    zmsadmin --> mellon & zmsclient & zmsslim & zmsentities;
    zmscalldisplay --> mellon & zmsclient & zmsentities & zmsslim;
    zmsstatistic --> mellon & zmsentities & zmsslim & zmsclient;
    zmsmessaging --> mellon & zmsclient & zmsentities & zmsslim;
    zmsticketprinter --> mellon & zmsclient & zmsentities & zmsslim;

    zmsdb --> zmsentities & zmsdldb & mellon;
    zmsclient --> zmsentities & zmsslim & mellon;
    zmsentities --> mellon;
    zmsslim --> mellon;

    %% zmscitizenapi dependencies
    zmscitizenapi --> mellon & zmsslim & zmsclient & zmsentities;

    %% Build dependencies (dashed lines)
    zmscitizenapi -.-> zmsapi;
    refarch-gateway -.-> zmscitizenapi;
    zmscitizenview -.-> refarch-gateway;

    %% Group refarch-gateway and zmscitizenview into a subgraph
    subgraph refarch [refarch]
        style refarch stroke-dasharray: 5
        refarch-gateway
        zmscitizenview
    end

    %% Group remaining modules into dashed PHP-style subgraph
    subgraph zms_modules [ZMS PHP Modules]
        style zms_modules stroke-dasharray: 5, 5, 1, 5
        zmsapi
        zmsadmin
        zmscalldisplay
        zmsstatistic
        zmsmessaging
        zmsticketprinter
        zmsdb
        zmsclient
        zmsentities
        zmsslim
        zmsdldb
        mellon
        zmscitizenapi
    end

    %% Styling for the three modules
    classDef citizenapi fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
    classDef gateway fill:#f3e5f5,stroke:#4a148c,stroke-width:2px;
    classDef citizenview fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px;

    class zmscitizenapi citizenapi;
    class refarch-gateway gateway;
    class zmscitizenview citizenview;

Zukünftige Architektur (3–5 Jahre)

Das folgende Diagramm zeigt die geplante Zielarchitektur nach Refactoring gemäß RefArch-Standards:

%%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
graph TD;
    %% Frontend Applications (Vue.js)
    zmsadmin_vue[zmsadmin<br/>Vue.js Frontend]
    zmsstatistic_vue[zmsstatistic<br/>Vue.js Frontend]
    zmscalldisplay_vue[zmscalldisplay<br/>Vue.js Frontend]
    zmsticketprinter_vue[zmsticketprinter<br/>Vue.js Frontend]
    zmscallcenter_vue[zmscallcenter<br/>Vue.js Frontend]
    zmscitizenview_vue[zmscitizenview<br/>Vue.js Frontend]

    %% API Gateways
    internal_gateway[Internal API Gateway<br/>SSO/Keycloak<br/>for Workers]
    citizen_gateway[External Citizen API Gateway<br/>SSO/Keycloak<br/>for BundID/BayernID]

    %% Backend Services
    zmsbackend[zmsbackend<br/>Spring Boot]
    zmscitizenapi[zmscitizenapi<br/>Spring Boot]
    zmsmessaging[zmsmessaging<br/>Spring Boot EAI]
    zmsdldb[zmsdldb<br/>Spring Boot EAI]
    other_eai[Other EAI<br/>Spring Boot EAI]

    %% External Systems
    stadt_muenchen[Stadt München<br/>Services/Locations]
    external_apis[Other External APIs<br/>and Services<br/>e.g Online Payments, Online Business Transactions]
    messaging_eai[e.g. Email Server,<br/>SMS Server,<br/>even Mobile App Push Notification Server]

    %% Internal Frontend Dependencies
    zmsadmin_vue --> internal_gateway;
    zmsstatistic_vue --> internal_gateway;
    zmscalldisplay_vue --> internal_gateway;
    zmsticketprinter_vue --> internal_gateway;
    zmscallcenter_vue --> internal_gateway;

    %% Citizen Frontend Dependencies
    zmscitizenview_vue --> citizen_gateway;

    %% API Gateway Dependencies
    internal_gateway --> zmsbackend;
    citizen_gateway --> zmscitizenapi;

    %% Backend Service Dependencies
    zmscitizenapi --> zmsbackend;
    zmsmessaging --> zmsbackend;
    zmsdldb --> stadt_muenchen;
    zmsmessaging --> messaging_eai;
    other_eai --> external_apis;

    %% EAI Integration
    zmsmessaging -.-> zmsdldb;
    zmsdldb -.-> zmsbackend;

    %% Group Frontend Applications
    subgraph frontends [Frontend Apps - Vue]
        style frontends fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
        zmsadmin_vue
        zmsstatistic_vue
        zmscalldisplay_vue
        zmsticketprinter_vue
        zmscallcenter_vue
        zmscitizenview_vue
    end

    %% Group API Gateways
    subgraph gateways [API Gateways - Spring]
        style gateways fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
        internal_gateway
        citizen_gateway
    end

    %% Group Backend Services
    subgraph backend [Backend Services - Spring]
        style backend fill:#e8f5e8,stroke:#388e3c,stroke-width:2px
        zmsbackend
        zmscitizenapi
        zmsmessaging
        zmsdldb
        other_eai
    end

    %% RefArch System Boundary
    subgraph refarch_system [ZMS RefArch]
        style refarch_system fill:#f8f9fa,stroke:#6c757d,stroke-width:3px,stroke-dasharray: 5 5
        frontends
        gateways
        backend
    end

    %% Group External Systems
    subgraph external [External Systems]
        style external fill:#fff3e0,stroke:#f57c00,stroke-width:2px
        stadt_muenchen
        external_apis
        messaging_eai
    end

    %% Position external systems below RefArch
    refarch_system --> external;

    %% Styling
    classDef frontend fill:#e3f2fd,stroke:#1976d2,stroke-width:2px;
    classDef gateway fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
    classDef backend fill:#e8f5e8,stroke:#388e3c,stroke-width:2px;
    classDef external fill:#fff3e0,stroke:#f57c00,stroke-width:2px;

    class zmsadmin_vue,zmsstatistic_vue,zmscalldisplay_vue,zmsticketprinter_vue,zmscallcenter_vue,zmscitizenview_vue frontend;
    class internal_gateway,citizen_gateway gateway;
    class zmsbackend,zmscitizenapi,zmsmessaging,zmsdldb,other_eai backend;
    class stadt_muenchen,external_apis,messaging_eai external;

Wesentliche Architekturänderungen

• Frontend-Modernisierung: Alle Frontend-Module werden zu Vue.js-Anwendungen
• API-Gateway-Muster: Getrennte Gateways für interne und bürgerorientierte Anwendungen
• Backend-Refactoring: Kerndienste werden nach Spring Boot migriert (zmsbackend)
• EAI-Dienste: zmsmessaging und zmsdldb als eigene Spring-Boot-EAI-Dienste
• Externe Integration: zmsdldb übernimmt Stadt-München-Leistungen/-Standorte-Mapping
• Microservices-Architektur: Klare Zuständigkeit durch dedizierte Dienste

Wesentliche Architekturänderungen (Detail)

• Frontend-Modernisierung: Alle Frontend-Module werden zu Vue.js-Anwendungen
• API-Gateway-Muster: Getrennte Gateways für interne und bürgerorientierte Anwendungen
• Backend-Refactoring: Kern nach Spring Boot konsolidiert: zmsapi, zmsdb, zmsclient, zmsentities, zmsslim, mellon → (zmsbackend)
• zmsmessaging: Dedizierter EAI-Dienst für Benachrichtigungen
• zmsdldb: EAI-Dienst für Stadt-München-Datenintegration mit zmsdldbmapper; weitere Mapper für andere Städte möglich
• Microservices-Architektur: Klare Zuständigkeit durch dedizierte Dienste

Architektur-Transformationen

Aspekt	Ist	Soll	Nutzen
Frontend	Gemischte PHP/Twig-Templates	Vue.js-SPA-Anwendungen	Moderne UX, bessere Wartbarkeit
API-Schicht	Direkte Service-Aufrufe	RefArch-API-Gateways	Zentralisierte Sicherheit, Monitoring
Backend	PHP-Monolith	Spring-Boot-Microservices	Bessere Skalierbarkeit, Wartbarkeit
EAI	Integriertes Messaging	Dedizierte EAI-Dienste	Klare Trennung
Externe Integration	Direkter DB-Zugriff	Serviceorientierte Integration	Bessere Daten-Governance

Aufwandsschätzung

Komponente	Aufgabe	Schätzung	Schwierigkeit
zmsdldbmapper	Open-Source-Stellung	4 Wochen	Mittel
zmsdldbmapper, zmsdldb	Ein Modul nach Spring Boot EAI	8 Wochen	Mittel
zmsmessaging	Nach Spring Boot EAI	4 Wochen	Einfach
zmsdeployment	Open-Source-Stellung	8 Wochen	Schwer
zmscallcenter	Neue Vue/Vuetify-UI + API-Gateway mit SSO	8 Wochen	Einfach
zmscalldisplay	Refactoring zu Vue/Vuetify + API-Gateway	4 Wochen	Einfach
zmsticketprinter	Refactoring zu Vue/Vuetify + API-Gateway	4 Wochen	Einfach
zmsstatistic	Refactoring zu Vue/Vuetify + API-Gateway mit SSO	8 Wochen	Mittel
zmsadmin	Refactoring zu Vue/Vuetify + API-Gateway mit SSO	9–12 Monate	Sehr schwer
zmsdb, zmsentities, zmsapi, zmscitizenapi, mellon, zmsclient, zmsslim	Backend-Refactoring zu Spring Boot (RefArch)	18–24 Monate	Sehr schwer

*Die Roh-Schätzung für die Entwicklung umfasst kein UI/UX, Planung, Testing usw.

---

Verwandte Issues

• ZMSKVR-685 – Testautomatisierung Einrichtung
• ZMSKVR-686 – Testautomatisierung Umsetzung
• ZMSKVR-795 – CalendarView-Refactoring
• #1427 – Datenbank-Standardisierung