diff --git a/template/i18n/de/adr-template.md b/template/i18n/de/adr-template.md index 1269ea3..f0e5b20 100644 --- a/template/i18n/de/adr-template.md +++ b/template/i18n/de/adr-template.md @@ -73,75 +73,3 @@ Entspricht das gewählte Design und seine Implementierung der Entscheidung? Z.B. ## Weitere Informationen {Hier können zusätzliche Hinweise/oder die Zuversichtlichkeit bzgl. des Entscheidungsergebnisses angeführt und/oder die Zustimmung des Teams zur Entscheidung dokumentiert und/oder festlegt werden, wann/wie diese Entscheidung umgesetzt werden soll und ob/wann die Entscheidung erneut überprüft werden sollte. Links zu anderen Entscheidungen und Ressourcen können hier ebenfalls erscheinen.} -status: "{vorgeschlagen | abgelehnt | akzeptiert | überholt | … | ersetzt durch ADR-0123" -datum: {YYYY-MM-DD Datum, an dem die Entscheidung zuletzt verändert wurde} -entscheidende: {Zählt alle an der Entscheidung beteiligten Personen auf} -beratende: {Zählt alle Personen auf, die nach ihrer Meinung gefragt wurden (typischerweise Spezialisten); Feedback gebende Personen sollten hier gelistet werden} -informierte: {Zählt alle Personen auf, die über den Fortschritt informiert werden; Personen, die informiert wurden, aber kein Feedback gaben, sollten hier gelistet werden.} ---- - -# {Kurzer Titel, der das gelöste Problem und die gefundene Lösung beschreibt} - -## Kontext und Problemstellung - -{Beschreibt den Kontext und die Problemstellung, z.B. in zwei bis drei Sätzen freiem Text oder in der Form einer Geschichte, die das Problem veranschaulicht. Eine gute Form, das Problem auszudrücken, ist auch eine Frage. Ggf. noch Links zu Boards oder Ticketing System.} - - -## Entscheidungsfaktoren - -* {Entscheidungsfaktor 1, z.B. ein Einfluss, ein Bedenken, …} -* {Entscheidungsfaktor 2, z.B. ein Einfluss, ein Bedenken, …} -* - -## Betrachtete Varianten - -* {Titel der Variante 1} -* {Titel der Variante 2} -* {Titel der Variante 3} -* … - -## Entscheidung - -Gewählte Variante: "{Titel der Variante 1}", denn {Begründung, z.B. die einzige Variante, die kein Ausschlusskriterium beinhaltet | … | am besten abschneidet (siehe unten)}. - - -### Konsequenzen - -* Gut, weil {positive Konsequenz, z.B. Verbesserung einer oder mehrerer gewünschter Eigenschaften, …} -* Schlecht, weil {negative Konsequenz, z.B. Einschränkung einer oder mehrerer gewünschter Eigenschaften, …} -* … - - -### Verifikation - -{Beschreibt, wie die Implementierung/Einhaltung geprüft werden kann/wird. -Entspricht das gewählte Design und seine Implementierung der Entscheidung? Z.B. kann eine Design-/Code-Review oder ein Test mit einer Bibliothek wie ArchUnit dabei helfen, dies zu prüfen. Beachtet, dass wir dieses Element zwar als optional einstufen, es aber in vielen ADRs enthalten ist.} - - -## Vor- und Nachteile der Varianten - -### {Titel der Variante 1} - - -{Beispiel | Beschreibung | Verweis auf weitere Informationen | …} - -* Gut, weil {Argument a} -* Gut, weil {Argument b} -* -* Neutral, weil {Argument c} -* Schlecht, weil {Argument d} -* … - -### {Titel einer anderen Variante} -{Beispiel | Beschreibung | Verweis auf weitere Informationen | …} - -* Gut, weil {Argument a} -* Gut, weil {Argument b} -* Neutral, weil {Argument c} -* Schlecht, weil {Argument d} -* … - - -## Weitere Informationen - -{Hier können zusätzliche Hinweise/oder die Zuversichtlichkeit bzgl. des Entscheidungsergebnisses angeführt und/oder die Zustimmung des Teams zur Entscheidung dokumentiert und/oder festlegt werden, wann/wie diese Entscheidung umgesetzt werden soll und ob/wann die Entscheidung erneut überprüft werden sollte. Links zu anderen Entscheidungen und Ressourcen können hier ebenfalls erscheinen.}