DerArchitekturkompass.de

Wie funktioniert es?

Die Datenbank der Schadenanwendung wächst durch hochgeladene Schadenfotos um etwa 200 GB im Monat. Das Betriebsteam betreibt und sichert die Datenbank. Das Betriebsteam meldet dem Entwicklungsteam, dass die nächtliche Sicherung der Datenbank morgens noch läuft, wenn die Sachbearbeiter mit der Arbeit beginnen. Das Entwicklungsteam prüft zwei Möglichkeiten. Die erste ist, die Fotos als Dateien auf der Festplatte eines Servers abzulegen. Das Entwicklungsteam verwirft diese Möglichkeit, weil die Schadenanwendung auf mehreren Servern läuft, auf jedem Server ein Exemplar desselben Programms. Jedes Exemplar muss auf dieselben Fotos zugreifen, doch die Festplatte eines Servers erreicht nur das Exemplar auf diesem Server. Die zweite ist der Objektspeicher, aus dem jedes berechtigte Programm eine Datei über eine Adresse abruft. Das Entwicklungsteam wählt den Objektspeicher. Als Folge hält es fest, dass Fotos und Schadendaten künftig getrennt gesichert werden müssen und dass beim Wiederherstellen beide Sicherungen zueinander passen müssen. Das Entwicklungsteam schreibt Ausgangslage, Entscheidung, verworfene Möglichkeit und Folgen in ADR 008 und legt ADR 008 mit dem Status „angenommen“ im Repository ab, der gemeinsamen Ablage für Programmcode und ADRs. Das Repository speichert jede Änderung mit Datum und Verfasser. Ein Jahr später will ein neuer Entwickler die Fotos wieder in die Datenbank legen, damit alle Schadendaten an einem Ort liegen, und sucht nach der Begründung. Er liest ADR 008 im Repository, sieht das Sicherungsproblem und die verworfene Dateilösung und versteht die Entscheidung, ohne jemanden fragen zu müssen, der damals dabei war. Hätte sich die Lage wesentlich geändert, würde der neue Entwickler ein neues ADR vorschlagen, und ADR 008 bekäme den Status „abgelöst durch“. Eine solche Änderung wäre zum Beispiel eine neue Datenbank mit schnellerer Sicherung.

Wie ein Softwaresystem grundsätzlich aufgebaut ist, entscheidet ein Entwicklungsteam meist in Besprechungen: welche Datenbank das System nutzt, wo Dateien liegen, wie Programme Daten austauschen. Solche Architekturentscheidungen bestimmen den Grundaufbau des Systems und lassen sich nur mit viel Aufwand ändern. Für jede Architekturentscheidung schreibt das Entwicklungsteam ein eigenes kurzes Dokument, meist eine Textdatei im selben Repository wie der Programmcode. Bewährt hat sich ein fester Aufbau:

• Am Anfang stehen eine Nummer und ein Titel, etwa „ADR 008: Schadenfotos im Objektspeicher ablegen“. Die Nummer macht das Dokument eindeutig auffindbar.
• Der Status lautet „vorgeschlagen“, solange die Entscheidung noch zur Abstimmung steht, danach „angenommen“ und später womöglich „abgelöst durch ADR 027“.
• Die Ausgangslage beschreibt, welches Problem zu lösen war und welche Bedingungen damals galten.
• Die Entscheidung sagt in einem oder zwei Sätzen, was das Entwicklungsteam gewählt hat.
• Unter den verworfenen Möglichkeiten steht, was noch zur Wahl stand und warum das Entwicklungsteam es nicht gewählt hat. Dieser Teil verhindert am wirksamsten, dass dieselbe Diskussion wieder beginnt.
• Die Folgen nennen, was durch die Entscheidung leichter und was schwerer wird.

Ein ADR macht eine Entscheidung nicht richtiger und hindert niemanden daran, sie zu ändern. Wer die Fotos später doch wieder in der Datenbank ablegen will, kennt durch ADR 008 aber den damaligen Grund, die zu lange nächtliche Sicherung.

Ein angenommenes ADR wird inhaltlich nicht mehr geändert, damit nachvollziehbar bleibt, was wann entschieden wurde. Ändert das Entwicklungsteam später seine Meinung, schreibt es ein neues ADR, und beide Dokumente verweisen aufeinander. Tippfehler darf man berichtigen; die ursprüngliche Begründung bleibt dabei erhalten.

ADR 008: warum Schadenfotos im Objektspeicher liegen

Wann ist es sinnvoll und wann nicht?