Enterprise Engineering Operating System verwenden

Zweck

Dieser Guide erklärt, wie das eingefrorene Enterprise Engineering Operating System (EEOS) als Senior Java Developer, Software Architect, Platform Engineer, DevOps Engineer, SRE oder Lernender verwendet wird.

Die Plattform ist keine IDE und kein einzelnes Lehrbuch. Sie verbindet Wissensbasis, Referenzsysteme, Architekturentscheidungen, ausführbare Werkzeuge, Qualitätsregeln, Runbooks, Simulationen und Governance.

1. Schnellstart

1. ZIP vollständig entpacken.
2. index.html im Browser öffnen.
3. Für den geführten Einstieg lernweg.html verwenden.
4. Den Bereich product-platform/index.html für die produktorientierte Übersicht öffnen.
5. Diesen Guide über WORKBENCH_GUIDE.html aufrufen.

Für iPhone und iPad steht zusätzlich iphone-safari.html bereit. Die HTML-Oberfläche funktioniert vollständig offline.

2. Orientierung in der Oberfläche

Kopfzeile

Die Kopfzeile bietet Startseite, Schriftgröße, Akzentfarbe und Hell-/Dunkelmodus. Die Auswahl wird lokal im Browser gespeichert.

Linke Navigation

Die Navigation ist nach Produkten und Arbeitsbereichen gegliedert. Über das Filterfeld lassen sich Kapitel schnell finden. Gruppen können ein- und ausgeklappt werden.

Command Palette

Mit Ctrl+K unter Windows/Linux oder ⌘K auf macOS wird die globale Command Palette geöffnet. Sie dient zum schnellen Wechsel zwischen Produkten, Referenzsystemen, Quality Center, Generator, Migration Assistant und weiteren Bereichen.

Breadcrumbs und Kontextleiste

Breadcrumbs zeigen die aktuelle Position. Die Kontextleiste nennt – soweit verfügbar – Produkt, Owner, Status, Version, Quality Gate, verwandte Inhalte und Evidence.

Codeblöcke und Diagramme

Codeblöcke verwenden ein JetBrains-Dark-Theme, Zeilennummern, Copy-Funktion und horizontales Scrollen. Diagramme besitzen lokale Zoom-Steuerung und bleiben offlinefähig.

3. Die wichtigsten Produktbereiche

Engineering Core

Für Java, JVM, Maven, Spring, DDD, Architektur, Patterns, Testing, Security, Performance, Refactoring und Senior Engineering.

Enterprise Platform

Für Kubernetes, CI/CD, Observability, Supply Chain, Golden Paths, Developer Self-Service und Plattformstandards.

Reference Systems

Für zusammenhängende fachliche Referenzsysteme. Banking 2.1 zeigt insbesondere Ledger, Transfer, Outbox, Idempotenz, Compliance, Audit, Reconciliation und Betriebsnachweise.

Enterprise Academy

Für Lernpfade, Katas, Assessments, Interviewvorbereitung und Zertifizierung.

AI Engineering

Für rollenbasierte Reviews durch Architect, Senior Java Developer, Platform Engineer, Security Engineer, DBA und SRE. Ergebnisse sind Empfehlungen; menschliche Freigaben bleiben erforderlich.

Quality Center

Für Architecture Fitness, Vertragskompatibilität, Supply Chain, Evidence, statische HTML-Prüfung und Release-Nachweise.

Project Generator

Für das Erzeugen neuer Java-21-Projekte nach Golden-Path-Regeln. Der Generator dokumentiert verwendete Entwurfsmuster im Code und in docs/design-patterns.md.

Migration Assistant

Für planbare Migrationen wie Java 17 auf 21, Spring Boot 3 auf 4 oder Monolith zu modularem Monolithen – jeweils mit Risiken, Tests, Rollout und Rollback.

Engineering Graph und Digital Thread

Für die Rückverfolgung von ADR über Service, Java-Code, API, Event, Migration, Tests und Runbook.

Command Center

Für Produktstatus, Owner, Quality Gates, Releases, Risiken, Security, Performance und offene externe Abnahmen.

4. Typischer Ablauf für einen Senior Java Developer

1. Im Dashboard oder Developer Portal das betroffene Produkt öffnen.
2. Fachlichen Kontext und vorhandene ADRs prüfen.
3. Engineering Graph oder Digital Thread nutzen, um Auswirkungen zu verstehen.
4. Passende Referenzimplementierung und Patterns öffnen.
5. Änderung mit TDD planen und Tests festlegen.
6. API-, Event- und Datenbankkompatibilität kontrollieren.
7. Architecture Fitness und Quality Gates ausführen.
8. Runbook, Observability und Rollback aktualisieren.
9. Evidence und Änderungsdokumentation ergänzen.
10. Release nur mit nachvollziehbaren Nachweisen freigeben.

5. Typischer Ablauf für einen Software Architect

1. Command Center und offene Risiken prüfen.
2. Architecture Intelligence und Engineering Graph öffnen.
3. Bounded Context, Invarianten und Transaktionsgrenzen bewerten.
4. Alternativen im Decision Workspace vergleichen.
5. ADR mit Konsequenzen, Risiken, Migration und Rückbau dokumentieren.
6. Architecture Fitness Functions definieren oder erweitern.
7. Evidence-Anforderungen und Review-Verantwortliche festlegen.
8. Entscheidung nach menschlichem Review freigeben.

6. Typischer Ablauf für Platform/DevOps/SRE

1. Service im Developer Portal identifizieren.
2. Golden Path, Deployment, SLO und Runbook prüfen.
3. Kubernetes-, CI/CD- und Observability-Artefakte kontrollieren.
4. Failure Injection oder Simulation World für Fehlerfälle verwenden.
5. Logs, Metriken, Traces, RTO und RPO bewerten.
6. Supply-Chain- und Security-Gates ausführen.
7. Recovery- und Rollback-Nachweise dokumentieren.
8. Offene externe Abnahmen sichtbar belassen.

7. Neuen Service erzeugen

Beispielablauf:

cd ecosystem/project-generator

Danach:

1. fachlichen Owner und Bounded Context festlegen,
2. Blueprint konfigurieren,
3. Projekt erzeugen,
4. erzeugte ADR und Pattern-Dokumentation prüfen,
5. Tests und Architecture Fitness ausführen,
6. Deployment, Telemetrie, SLO und Runbook ergänzen,
7. Produkt- oder Service-Registry aktualisieren,
8. Evidence sichern.

8. Quality Gates ausführen

Je nach Bereich stehen mehrere Prüfskripte zur Verfügung. Der zentrale Einstieg ist im Root dokumentiert, beispielsweise:

./check-all.sh

Wichtig: Ein SKIP ist kein Fehler, aber auch kein bestandener Nachweis. Docker, Testcontainers, externe Security-Scanner oder reale Geräteprüfungen werden nur als bestanden gewertet, wenn sie tatsächlich ausgeführt wurden.

9. Reference Systems richtig verwenden

Reference Systems sind Entscheidungs- und Lernrahmen, keine ungeprüften Produktionsvorlagen.

Empfohlene Nutzung:

1. fachliche Regeln verstehen,
2. Aggregate und Transaktionsgrenzen vergleichen,
3. Ports, Adapter und Events nachvollziehen,
4. Tests und Failure Modes prüfen,
5. auf die eigene Domäne übertragen,
6. Abweichungen durch ADR dokumentieren.

10. Lernen mit der Academy

Ein sinnvoller Lernzyklus lautet:

1. Überblick lesen,
2. Deep Dive bearbeiten,
3. Referenzcode nachvollziehen,
4. Kata oder Simulation durchführen,
5. Code Review lösen,
6. Produktionsfall analysieren,
7. Assessment oder Interviewfragen bearbeiten,
8. Lessons Learned dokumentieren.

11. Lokale Daten, Import und Export

Interaktive Bereiche speichern Arbeitsstände lokal im Browser. Für Sicherung und Übertragung stehen die Workspace-Backup-Funktionen zur Verfügung.

Vor Browserwechsel, Gerätewechsel oder Reset:

1. JSON-Backup exportieren,
2. optional Markdown-Bericht exportieren,
3. Backup außerhalb des Projektordners sichern,
4. Import in einer Testsession prüfen.

12. Häufige Fragen

Funktioniert die Workbench ohne Internet?

Ja. Die HTML-Oberfläche verwendet keine externen CDN-Abhängigkeiten.

Kann ich direkt in diesem eingefrorenen Paket weiterentwickeln?

Nein. Der Stand ist als FROZEN archiviert. Für Änderungen eine vollständige Kopie mit neuem Release-Namen erstellen.

Ist die Workbench eine IDE?

Nein. Quellcode wird in einer IDE bearbeitet. Die Workbench liefert Kontext, Standards, Beispiele, Generatoren, Reviews und Quality Gates.

Sind alle Infrastrukturtests bestanden?

Nur die im Prüfbericht ausdrücklich als bestanden markierten Tests. Docker-, Testcontainers-, Scanner- und reale Geräteprüfungen können als externe Abnahme offen sein.

Wo beginne ich bei einer konkreten Änderung?

Im Developer Portal oder Command Center das Produkt auswählen, dann ADR, Engineering Graph, Referenzcode, Tests, Runbook und Quality Gates in dieser Reihenfolge prüfen.

13. Erster Arbeitstag – empfohlene Route

1. index.html
2. lernweg.html
3. product-platform/index.html
4. Developer Cockpit
5. Banking Reference System
6. Engineering Graph / Digital Thread
7. Quality Center
8. Project Generator
9. Workspace Backup
10. FROZEN_RELEASE.html

14. Freeze-Regel

Dieses Paket ist ein unveränderlicher Referenzstand. Dokumentierte Archivergänzungen verändern keine fachlichen oder technischen Inhalte. Jede echte Weiterentwicklung erfolgt in einer neuen Arbeitskopie mit:

• neuem Verzeichnisnamen,
• neuer Versions- oder Produktkennung,
• aktualisiertem Changelog,
• neuen Prüfberichten,
• erneuerter SHA-256-Prüfsumme,
• neuem Gesamt-ZIP.