Werkzeuge & Methoden
Wähle deine Aufgabe. Vergleiche, was die Werkzeuge liefern – und steige dort ein, wo du weiterkommst.
Welche Fähigkeiten und Qualitäten braucht der Shop?
Kläre, was der Shop leisten und wie gut er es tun soll.
Anforderungen
Beobachtbare, prüfbare Fähigkeit
Am ShopEin Kunde gibt seinen Warenkorb als Bestellung auf, und der Shop vergibt die Bestellkennung B-1042.
Anforderungen
Priorisierte und prüfbare Qualitätsziele
Am ShopIllustrativ: 95 % der Zahlungsantworten kommen innerhalb von 800 ms bei 20 Anfragen pro Sekunde.
Wo gelten Begriffe und Regeln jeweils?
Schneide fachliche Zuständigkeiten und Integrationsbeziehungen passend zu.
Domäne
Klare fachliche Modelle mit benannten Grenzen
Am ShopBestellung und Rechnung kennen beide „Betrag“ und „Status“, meinen damit aber Unterschiedliches und erhalten deshalb getrennte Modelle.
Domäne
Verständliche Abhängigkeiten zwischen Fachmodellen
Am ShopLager, Zahlung und Bestellung stimmen sich im Team ab; der Zahlungsanbieter gibt sein Modell vor, der Shop übersetzt.
Methode im Baustein Domain-Driven Design
Gemeinsames Prozessbild mit offenen Fragen
Am ShopDas Team ordnet „Bestellung aufgegeben“, „Zahlung autorisiert“ und „Bestand reserviert“ und klärt, wann eine Bestellung als bestätigt gilt.
Welche Option passt am besten und warum?
Vergleiche Entwurfsoptionen und halte die Entscheidung fest.
Evolution
Begründete Wahl mit sichtbaren Konsequenzen
Am ShopModularer Monolith oder getrennte Services: Das Team wägt Änderungsautonomie gegen Betriebs- und Netzwerkaufwand ab.
Dokumentation
Nachvollziehbare Entscheidung samt Konsequenzen
Am ShopDas ADR hält fest, dass der Shop ein modularer Monolith bleibt, und nennt die Betriebsfolgen.
Wie sehen Bausteine, Abläufe und Betrieb aus?
Mache Struktur, Ablauf und Betrieb des Shops sichtbar und dokumentiere sie.
Dokumentation
Abgestimmte Sichten auf Grenzen und Bausteine
Am ShopDu zeigst Kundinnen, Zahlungsanbieter und Shop als Kontext sowie Webanwendung, modularen Monolithen und Datenbank als Container.
Dokumentation
Nachvollziehbarer Ablauf samt kritischer Alternativen
Am ShopBestellung, Zahlung und Anbieter klären P-731; bei verlorener Antwort fragt der Shop den Zahlungsstatus ab.
Dokumentation
Sichtbare Laufzeitabhängigkeiten
Am ShopDie Shop-Anwendung läuft auf zwei Instanzen mit verwalteter Datenbank; der Zahlungsanbieter bleibt extern.
Dokumentation
Konsistente Architekturdokumentation fürs Team
Am ShopDie Shop-Dokumentation verknüpft das Ziel für Bestellbestätigungen mit Zahlungsablauf, ADR zur Modulstruktur und dem offenen Restore-Risiko.
Trägt die Architektur und wo sind Risiken offen?
Prüfe Architekturannahmen früh und wiederholbar.
Evolution
Konkrete Befunde und vereinbarte Maßnahmen
Am ShopDas Team verfolgt den Bestellabschluss bei verzögerter Zahlungsantwort und prüft Statusmodell, Wiederaufnahme und Betriebsindikatoren.
Evolution
Frühe Rückmeldung zu Architekturregeln
Am ShopEin automatischer Test markiert unerlaubte Datenbankzugriffe zwischen Bestell-, Versand- und Rechnungsmodul außerhalb der Modulverträge.
Security
Priorisierte Bedrohungen mit Gegenmaßnahmen
Am ShopDas Team fragt bei einer eingehenden Versandmeldung, ob ein kompromittierter Partner fremde Bestellstatus ändern könnte.
Dokumentation
Priorisierte Risiken mit konkreten nächsten Schritten
Am ShopDer Restore mit Zahlungsabgleich ist noch nicht erprobt; das Log nennt Verantwortliche und den Nachweis.
Wie erkennt und begrenzt das Team kritische Fehler?
Plane Zuverlässigkeit und Wiederanlauf für den Shop.
Betrieb
Messbares Zuverlässigkeitsziel mit Handlungsregel
Am ShopBestellbestätigungen sollen innerhalb von zwei Sekunden sichtbar sein, illustrativ mit 99,0 % oder 99,5 % über 30 Tage und Reaktionsregel.
Betrieb
Belegter Wiederherstellungsweg mit Messwerten
Am ShopNach Schaden am Bestellindex stellt das Team isoliert wieder her und gleicht die Bestellungen mit dem Zahlungssystem ab.