Constraints
Constraints begrenzen den Lösungsraum durch verbindliche Vorgaben. Sie werden als gegebene Bedingung dokumentiert und auf ihren Ursprung geprüft.
- ConstraintVerbindliche Vorgabe von außen.
- ArtTechnisch, organisatorisch, rechtlich oder Konvention.
- UrsprungHerkunft zeigt, wer es ändern darf.
Einordnung
Warum das wichtig ist
Wer eine eigene Wahl für eine Vorgabe hält, schließt Lösungen aus, ohne es zu merken. Wer eine echte Vorgabe ignoriert, plant am Vertrag vorbei. Wie du Entscheidungen festhältst, zeigt ein eigener Baustein.
Dieser Baustein erklärt feste Randbedingungen. Für die Priorisierung aller prägenden Einflüsse, auch der abwägbaren, siehe Architekturtreiber.
Auf einen Blick · Vorgaben begrenzen den Lösungsraum
Fest vorgegeben oder gestaltbar?
Der Shop trägt technische Constraints (Zahlungsanbieter, Java-Laufzeit), organisatorische (kleines Team ohne Rufbereitschaft), rechtliche (DSGVO, PCI DSS) und eine Konvention (API-Richtlinie). Auslieferung und Modulzuschnitt bleiben Entscheidungen des Teams.
So liest du das Bild
- Constraint Die Zeilen mit „fest vorgegeben“, von Zahlungsanbieter bis Konventionen.
- Art Die Spalte „Art“: Sie zeigt, woher die Vorgabe stammt.
- Ursprung Die Spalten „Ursprung“ und „Wer kann es ändern?“ pro Zeile.
| Element | Art | Einordnung | Ursprung | Wer kann es ändern? | Wirkung auf den Entwurf |
|---|---|---|---|---|---|
| Zahlungsanbieter | technisch | fest vorgegeben | Vertrag | nur über den Vertrag | Adapter im Zahlungsmodul, Fehlerbehandlung gestaltbar |
| Laufzeit | technisch | fest vorgegeben | vorhandene Java-Laufzeit im Betrieb | der Betrieb | Frameworks und Bibliotheken auf der JVM wählen |
| Team | organisatorisch | fest vorgegeben | Budget: kleines Team, keine getrennte Rufbereitschaft | die Unternehmensleitung | spricht für modularen Monolithen statt vieler Dienste |
| Kundendaten | rechtlich | fest vorgegeben | DSGVO (EU-Verordnung) | der Gesetzgeber | Lösch- und Auskunftsfähigkeit einplanen |
| Kartenzahlung | regulatorisch | fest vorgegeben | PCI DSS (Branchenstandard, vertraglich bindend) | die Kartenorganisationen (PCI SSC) | keine Kartendaten speichern, nur Zahlungskennung des Anbieters |
| Konventionen | Konvention | fest vorgegeben | unternehmensweite API-Richtlinie | Architekturgilde bzw. Unternehmensarchitektur | Verträge folgen dem Hausstil |
| Auslieferung | Entscheidung | gestaltbar | Entscheidung des Teams | das Team | modularen Monolithen wählen oder neu bewerten |
| Modulzuschnitt | Entscheidung | gestaltbar | Entscheidung des Teams | das Team | Katalog bis Rechnung frei schneiden |
Nutzen & Grenzen
Hilft, wenn
- Verbindliche Rahmenbedingungen beeinflussen Technologie, Betrieb oder Schnittstellen.
- Eine geäußerte Vorgabe muss auf Verbindlichkeit und Eigentümerschaft geprüft werden.
Grenzen
- Eine Präferenz wird leicht als Vorgabe getarnt („Das müssen wir so machen“). Kläre Quelle und Entscheidungsbefugnis, bevor du sie als Constraint führst; sonst ordne sie als Architekturtreiber ein oder halte sie als Entscheidung fest.
- Constraints veralten: Verträge laufen aus, Plattformen werden abgelöst, Gesetze ändern sich. Halte einen Prüftermin fest und bewerte betroffene Entscheidungen neu, etwa im ADR.
In der Praxis
- Wortlaut und Quelle erfassen. Notiere, wer die Bedingung gesetzt hat und ob sie verbindlich ist. Das Ergebnis trennt überprüfbare Vorgaben von vorläufigen Präferenzen.
- Geltungsbereich und Entwurfswirkung ableiten. Bestimme betroffene Komponenten und ausgeschlossene Optionen. Unterscheide den Constraint von den übrigen, abwägbaren Zielen unter den Architekturtreibern.
- Nachweis und Überprüfung zuordnen. Lege fest, welche Rolle Erfüllung bestätigt und wann die Vorgabe erneut geprüft wird. Verknüpfe den Nachweis mit betroffenen Qualitätsattributen.
Ausführliche Erklärung lesen
Constraints können durch Gesetze, Verträge, bestehende Systeme, Zuständigkeiten oder verfügbare Ressourcen entstehen. Quelle, Geltungsbereich und Verbindlichkeit bestimmen, wie sie auf den Entwurf wirken. Architekturtreiber umfassen sowohl solche Grenzen als auch priorisierte Ziele; Qualitätsattribute beschreiben dagegen gewünschte Eigenschaften des Systemverhaltens.
Eine Vorgabe kann Optionen ausschließen und Folgefragen zu Datenhaltung, Zugriff oder Betrieb erzeugen. Halte deshalb neben dem Wortlaut auch Eigentümer, Nachweis und Überprüfungszeitpunkt fest. So kann das Team unterscheiden, welche Bedingungen gesetzt sind und welche Präferenzen noch verhandelt werden können.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wer kann die Vorgabe zur Kartenzahlung ändern, und wer die Auslieferung?
Lösung mit Begründung ansehen
Die Vorgabe zur Kartenzahlung nur die Kartenorganisationen über den PCI Security Standards Council; die Auslieferung das Team per Entscheidung.
AnwendenAuf eine neue Lage übertragen
Das Marketing will Kartendaten für Ein-Klick-Käufe im Shop speichern. Was steht dem entgegen, und wer kann es ändern?
Lösung mit Begründung ansehen
PCI DSS, ein Branchenstandard der Kartenorganisationen; ändern können es nur sie. Alternative: Nur die Zahlungskennung (Token) des Anbieters speichern, die Kartendaten bleiben dort.
BewertenEine Alternative abwägen
Soll das Team den modularen Monolithen wie einen Constraint behandeln, damit er nicht ständig diskutiert wird?
Lösung mit Begründung ansehen
Das schafft Ruhe, verbirgt aber, dass es eine Entscheidung ist. Gestaltbare Wahlen müssen bei verändertem Kontext neu bewertet werden dürfen. Besser: als Entscheidung mit Gründen festhalten.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- arc42 · Kapitel 2: Randbedingungen (öffnet in neuem Tab)Technische und organisatorische Vorgaben explizit festhalten.
- DSGVO (Verordnung (EU) 2016/679) bei EUR-Lex (öffnet in neuem Tab)Amtlicher Text der EU-Verordnung zum Schutz personenbezogener Daten.
- PCI Security Standards Council (öffnet in neuem Tab)Herausgeber des Branchenstandards PCI DSS für Kartenzahlungen.