Architecture Decision Record

Architektur-Decisiounsopzeechnung (ADR)

Virlagen, Beispiller a Guidance fir Architekturdecisiounen opzezeechnen.

Eng Architektur-Decisiounsopzeechnung (ADR) ass en Dokument, dat eng wichteg Architekturdecisioun zesumme mat hirem Kontext a séng Konsequenzen festhält.

Iwwersetzungen: العربية, বাংলা, Cymraeg, Dansk, Deutsch, English, Lietuvių, Gaeilge, Lëtzebuergesch, Malti, Latviešu, Slovenščina, Slovenčina, Hrvatski, Български, Čeština, Magyar, Ελληνικά, Română, Polski, Español, Eesti, Suomi, Français, हिन्दी, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Nederlands, Português, Русский, Svenska, Kiswahili, ไทย, Türkçe, اردو, Tiếng Việt, 中文

Maacht Är eege Due Diligence fir dës Ressourcen, ier Dir se a kriteschen Systemer benotzt.

Inhalt:

Virlagen:

Beispiller:

Wat ass eng Architektur-Decisiounsopzeechnung?

Eng Architektur-Decisiounsopzeechnung (ADR) ass en Dokument, dat eng wichteg Architekturdecisioun zesumme mat hirem Kontext a séng Konsequenzen festhält.

Eng Architekturdecisioun (AD) ass eng Entscheedung am Softwaredesign, déi eng wesentlech Ufuerderung adresséiert.

E Architekturdecisiounsprotokoll (ADL) ass d'Sammlung vun alle ADR, déi fir e bestëmmte Projet (oder eng Organisatioun) erstallt a gepflegt ginn.

Eng architekturrelevant Ufuerderung (ASR) ass eng Ufuerderung, déi e messbaren Effekt op d'Architektur vun engem Softwaresystem huet.

Dat alles gehéiert zum Thema Architekturwëssensmanagement (AKM).

D'Zil vun dësem Dokument ass et, e séieren Iwwerbléck iwwer ADR ze ginn, wéi een se erstellt, a wou een méi Informatioune fënnt.

Ofkierzungen:

  • AD: Architekturdecisioun

  • ADL: Architekturdecisiounsprotokoll

  • ADR: Architektur-Decisiounsopzeechnung

  • AKM: Architekturwëssensmanagement

  • ASR: architekturrelevant Ufuerderung

Wéi een mat ADR ufänkt

Fir mat ADR unzefänken, schwätzt mat Ären Teamkollegen iwwer dës Beräicher.

Decisiounsidentifikatioun:

  • Wéi dringend a wéi wichteg ass d'AD?

  • Muss si elo geholl ginn, oder kann se waarden, bis méi bekannt ass?

  • Souwuel perséinlech a kollektiv Erfahrung wéi och unerkannt Designmethoden a -praktike kënnen d'Identifikatioun vun Decisioune ënnerstëtzen.

  • Am Idealfall féiert een eng Decisiounslëscht, déi d'Produktlëscht ergänzt.

Decisiounsfannung:

  • Et gëtt eng Rei Techniken zur Decisiounsfannung, souwuel allgemeng wéi och speziell fir Softwarearchitektur, zum Beispill Dialogue Mapping.

  • D'Decisiounsfannung a Gruppen ass en aktivt Fuerschungsthema.

Duerchsetzung an Ëmsetzung vun Decisiounen:

  • AD ginn am Softwaredesign benotzt; dofir musse si de Stakeholder vum System, déi et finanzéieren, entwéckelen an bedreiwen, matgedeelt a vun hinnen akzeptéiert ginn.

  • Architektonesch evident Coding-Stiler a Code-Reviews, déi sech op Architekturthemen an -decisiounen konzentréieren, sinn zwou verwandte Praktiken.

  • AD musse bei der Moderniséierung vun engem Softwaresystem an der Softwareevolutioun och nei ënnersicht ginn.

Decisiounen deelen (optional):

  • Vill AD widderhuele sech a Projeten.

  • Dofir kënnen Erfahrungen mat fréieren Decisiounen, gutt wéi schlecht, wäertvoll wiederverwendbar Ressource sinn, wann ee mat enger explizitter Wëssensmanagement-Strategie schafft.

Decisiounsdokumentatioun:

  • Et gëtt vill Virlagen an Tools fir Decisiounen z'erfaassen.

  • Kuckt déi agil Gemeinschaften, z.B. d'ADR vum M. Nygard.

  • Kuckt traditionell Prozesser vun der Softwareentwécklung a vum Architekturdesign, z.B. Tabelleformater, déi vum IBM UMF a vum Tyree an Akerman vu CapitalOne virgeschloe ginn.

Fir méi:

Wéi een mat ADR a Verbindung mat Toole ufänkt

  • MySpec — Automatiséiert Spezifikatiouns- an Architekturdecisiounsplattform, déi d'Projetskonstitutioun, déi technesch Architektur an d'ADR a proppert Markdown strukturéiert, dat iwwer MCP zur Verfügung gestallt gëtt.

Dir kënnt ADR mat Toole sou benotzen, wéi et Iech gefält.

Zum Beispill:

  • Wann Dir gär Google Drive an Online-Editéiere benotzt, kënnt Dir en Google Doc oder e Google Sheet erstellen.

  • Wann Dir gär Quellcode-Versiounskontroll benotzt, wéi Git, kënnt Dir fir all ADR eng Datei erstellen.

  • Wann Dir gär Projetsplanungstools benotzt, wéi Atlassian Jira, kënnt Dir den Planungs-Tracker vum Tool benotzen.

  • Wann Dir gär Wikien benotzt, wéi MediaWiki, kënnt Dir e Wiki fir ADR erstellen.

Wéi een mat ADR a Verbindung mat Git ufänkt

Wann Dir gär Git-Versiounskontroll benotzt, hei ass, wéi mir gär mat ADR a Verbindung mat Git fir en typesche Softwareprojet mat Quellcode ufänken.

Erstellt en Verzeechnes fir d'ADR-Dateien:

$ mkdir adr

Erstellt fir all ADR eng Textdatei, zum Beispill choose-database.md:

$ vi choose-database.md

Schreift an den ADR alles, wat Dir wëllt. Kuckt d'Virlagen an dësem Repository fir Iddien.

Committed den ADR an Äre Git-Repo.

Claude-Code-Skills fir ADR

Dëse Repository liwwert zwee Claude Code-Skills ënner skills/, sou datt en AI-Coding-Agent ADR esou schreiwe an erhale kann, wéi dëse Projet et recommandéiert:

  • architecture-decision-record-skill — allgemeng, fir jiddereen, deen en ADR a irgendengem Projet schreift. Hëlleft ze entscheeden, ob eng Decisioun en ADR brauch, riicht e Verzeechnes adr/ oder decisions/ an, benennt d'Datei, wielt e Virlag aus den eelef matgelifferte Skeletter a schreift solid Kontext-/Decisioun-/Konsequenzen-Rubriken.

  • architecture-decision-record-maintainer-skill — speziell fir d'Maintainer vun dësem Repository. Dokumentéiert d'Layout vum Repository, d'Konventioun fir d'Spigelung vu README/Locales an déi exakt Schrëtt, fir en neie Virlag, e Beispill oder en Tool-Link derbäizesetzen.

Fir e Skill ze benotzen, kopéiert säin Dossier an .claude/skills/ an der Wuerzel vum Repository, an deem Dir schafft (oder an ~/.claude/skills/, fir en a jidde Projet verfügbar ze maachen), a freet dann Claude Code, en ADR ze schreiwen oder ze iwwerpréiwen.

Konventioune fir Dateinimm vun ADR

Wann Dir Är ADR mat typeschen Textdateie wëllt erstellen, wëllt Dir vläicht Är eege Konventioun fir d'Dateinimm vun ADR festleeën.

Mir bevirzugen eng Konventioun fir Dateinimm, déi e spezifescht Format huet.

Beispiller:

  • choose-database.md

  • format-timestamps.md

  • manage-passwords.md

  • handle-exceptions.md

Eis Konventioun fir Dateinimm:

  • Den Numm huet e Verbausdrock am Imperativ am Präsens. Dat hëlleft der Liesbarkeet a passt zu eisem Format fir Commit-Messagen.

  • Den Numm benotzt Klengbuschtawen a Bindestrécher (wéi an dësem Repo). Dat ass e Gläichgewiicht tëscht Liesbarkeet a Benotzbarkeet vum System.

  • D'Extensioun ass Markdown. Dat kann nëtzlech si fir einfach Formatéierung.

Virschléi fir gutt ADR ze schreiwen

Charakteristike vun engem gudden ADR:

  • Begrënnung: Erkläert d'Grënn, firwat déi bestëmmten AD geholl gëtt. Dat kann de Kontext (kuckt ënnen), Virdeeler an Nodeeler vu verschiddene méigleche Choixen, Featurevergläicher, Käschten-/Notze-Diskussiounen a méi enthalen.

  • Spezifesch: All ADR soll iwwer eng AD goen, net iwwer méi AD.

  • Zäitstempel: Haalt fest, wéini all Element am ADR geschriwwe gouf. Dat ass besonnesch wichteg fir Aspekter, déi sech mat der Zäit kënne änneren, wéi Käschten, Zäitplang, Skaléierung an Ähnleches.

  • Onverännerbar: Ännert keng bestoend Informatioun an engem ADR. Amplaz ergänzt den ADR mat neier Informatioun, oder léist den ADR duerch en neien ADR of.

Charakteristike vun enger gudder "Kontext"-Rubrik an engem ADR:

  • Erkläert d'Situatioun vun Ärer Organisatioun an d'Geschäftsprioritéiten.

  • Bezitt Begrënnungen an Iwwerleeungen mat an, déi op der sozialer a kompetenzbaséierter Zesummesetzung vun Ären Teams baséieren.

  • Bezitt Pro- a Kontra-Argumenter mat an, déi relevant sinn, a beschreift se esou, datt se zu Äre Bedürfnisser an Zieler passen.

Charakteristike vun enger gudder "Konsequenzen"-Rubrik an engem ADR:

  • Erkläert, wat aus der Decisioun follegt. Dat kann d'Effekter, d'Resultater, d'Outputs, d'Follow-ups a méi enthalen.

  • Bezitt Informatioune iwwer all nofollgend ADR mat an. Et ass relativ üblech, datt een ADR de Besoin u weidere ADR ausléist, zum Beispill wann een ADR eng grouss iwwergräifend Wiel mécht, déi dann de Besoin u méi klenge Decisiounen erstellt.

  • Bezitt all Review-Prozesser nom Handelen mat an. Et ass typesch, datt Teams all ADR een Mount méi spéit nokucken, fir d'ADR-Informatioun mat deem ze vergläichen, wat an der Praxis geschitt ass, fir ze léieren an ze wuessen.

E neien ADR ka vun engem fréiere ADR iwwerholl:

  • Wann eng AD geholl gëtt, déi e fréiere ADR ersetzt oder ongëlteg mécht, da soll en neien ADR erstallt ginn

ADR-Beispillvirlagen

ADR-Beispillvirlagen, déi mir am Netz gesammelt hunn:

Rotschléi fir d'Teamaarbecht bei ADR

Wann Dir iwwerleet, Decisiounsopzeechnungen an Ärem Team ze benotzen, hei sinn e puer Rotschléi, déi mir duerch d'Zesummenaarbecht mat ville Teams geléiert hunn.

Dir hutt d'Chance, Är Teamkollegen ze féieren, andeems Dir zesummen iwwer d'"Firwat" schwätzt, amplaz d'"Wat" virzeschreiwen. Zum Beispill sinn Decisiounsopzeechnungen e Wee fir Teams, intelligenter ze denken a besser ze kommunizéieren; Decisiounsopzeechnunge si wäertlos, wann se just eng nodréiglech erzwongen Pabeierfuerderung sinn.

E puer Teams bevirzugen den Numm "Decisiounen" däitlech virun der Ofkierzung "ADR". Wann e puer Teams de Verzeechnesnumm "decisions" benotzen, ass et wéi wann e Luucht usgeet, an d'Team fänkt un, méi Informatioun an d'Verzeechnes ze setzen, wéi Decisioune vu Lieferanten, Planungsdecisiounen, Terminplanungsdecisiounen, asw. All dës Zorte vun Informatioun kënnen dee selwechte Virlag benotzen. Mir stellen d'Hypothees op, datt d'Leit méi séier mat Wierder ("Decisiounen") léieren wéi mat Ofkierzungen ("ADR"), datt d'Leit méi motivéiert sinn, Dokumenter iwwer Aarbecht am Gaang ze schreiwen, wann d'Wuert "Opzeechnung" ewechfält, an datt e puer Entwéckler an e puer Manager d'Wuert "Architektur" net gär hunn.

An der Theorie ass Onverännerbarkeet ideal. An der Praxis huet Verännerbarkeet fir eis Teams besser geschafft. Mir setzen déi nei Informatioun an den bestoenden ADR an, mat engem Datumsstempel an enger Notiz, datt d'Informatioun no der Decisioun ukomm ass. Sou en Usaz féiert zu engem "liewegen Dokument", dat mir all aktualiséiere kënnen. Typesch Aktualiséierunge geschéien, wa mir Informatioun duerch nei Teamkollegen, nei Offeren, reell Resultater aus eiser Notzung, oder nodréiglech Ännerunge vun Drëttpartnere kréien, wéi Fäegkeete vu Lieferanten, Präispläng, Lizenzvereinbarungen, asw.

Froen zur Teamaarbecht bei ADR

Wien kann en ADR erstellen?

Berécksiichtegt Beräicher wéi spezifesch Persounen, spezifesch Rollen, spezifesch Teams oder spezifesch Departementer; berécksiichtegt och, ob et Persounen, Rollen, Teams oder Departementer gëtt, déi en ADR a Optrag ginn kënnen, dat heescht, si froen een un, deen een anere schreift.

Beispillantwert: All Persoun an eiser Organisatioun, déi d'README-Säit vun der Architektur-Decisiounsopzeechnung gelies huet, kann en ADR virschloen, dat heescht, d'Persoun ka mat der Schreiwen ufänken an en dem Team matdeelen.

Wat rechtfäerdegt et, en ADR unzeleeën?

Berécksiichtegt Beräicher wéi d'Aarbechtsweisen vun Ärer Organisatioun an Teams, d'Struktur vun Ärem Softwaresystem, d'Koordinatioun tëscht Teams, laangfristeg Wartbarkeet, extern Schnëttstellen, wiem Dir wëllt notzen, an Ähnleches.

Beispillantwert: Mir wëllen en ADR erstellen, wa mir wëllen, datt zukünfteg Entwéckler d'"Firwat" vun deem verstoen, wat mir maachen.

Wat rechtfäerdegt et, keen ADR unzeleeën?

Berécksiichtegt Beräicher wéi Decisiounen, déi net d'Architektur betreffen, oder winzeg sinn, zum Beispill mat minimalem Risiko oder selbststänneg oder fir en eenzegen Entwéckler, oder schonn anzwuesch voll ofgedeckt sinn, zum Beispill duerch Standarden oder Politiken oder Dokumentatioun, oder temporär sinn, zum Beispill Workarounds oder Proofs of Concept oder Experimenter.

Beispillantwert: Mir wëllen en ADR iwwersprangen, wann eng Decisioun a Géigewier vun Ëmfang, Zäit, Risiko a Käschte limitéiert ass, oder schonn anzwuesch ofgedeckt ass.

Wat ass de Lifecycle vun engem ADR?

Berécksiichtegt Beräicher wéi de Prozess vun der Erstellung, d'Recherche, de Prozess vun der Decisiounsfannung, d'Ëmsetzung an d'Ausleeë vun engem ADR. Berécksiichtegt, wéi de Lifecycle vum ADR mat der Zäit verfollegt gëtt, zum Beispill wéi de ADR vun engem Zoustand an deen nächsten bewegt gëtt, an och wéi dat de Stakeholder matgedeelt gëtt.

Beispillantwert: Mir wëllen, datt en ADR fënnef Lifecycle-Stadie huet: Initiéieren → Recherchéieren → Evaluéieren → Ëmsetzen → Erhalen → Ausleeën.

Wat sinn d'Critèrë fir d'Lifecycle-Schrëtt vun engem ADR?

Berécksiichtegt Beräicher wéi Akzeptanzcritèrë fir en ADR, dat heescht, wéi weess een, datt en gutt genuch ass, fir vun engem Lifecycle-Schrëtt an deen nächsten ze goen? Ass de Problem kloer formuléiert? Goufen d'Alternative berécksiichtegt? Sinn d'Kompromësser gutt genuch verstanen an dokumentéiert? Ass de ganze relevante Kontext do? Sinn all relevant Stakeholder involvéiert? Gouf all Feedback agebaut?

Beispillantwert: Mir wëllen, datt iwwer en ADR vun de Stakeholder ofgestëmmt gëtt, wann dat aktivt Team 1) seng Recherche ofgeschloss huet, 2) seng Evaluatioun ofgeschloss huet, 3) de Virschlag fir den ADR de Stakeholder mat enger Ufro fir Kommentare an enger Zäitbegrenzung vun enger Woch publizéiert huet, 4) all Kommentare vun de Stakeholder agebaut an adresséiert goufen.

Wéi eng Rolle a Verantwortlechkeeten interagéieren mat engem ADR?

Berécksiichtegt Rolle wéi Virschloender, Recherchéierer, Evaluator, Reviewer, Genehmegen, Maintainer an Ähnleches. Berécksiichtegt Verantwortlechkeeten wéi d'Kommunikatioun mat de Stakeholder, d'Gewährleeschtung, datt Erwaardunge erfëllt ginn, d'Deele vum Dokument um Site oder Intranet, an d'periodesch Iwwerpréiwung vun der Aarbecht, besonnesch wann relevant Ännerunge geschéien.

Beispillantwert: Mir wëllen, datt all ADR ëmmer eng primär Kontaktpersoun, eng sekundär Kontaktpersoun an en responsabelt Team huet; dës sinn zoustänneg fir Kommunikatiounen, Publikatiounen, Erhalung, periodesch Iwwerpréiwung op d'mannst eemol d'Joer, an eventuell Ausleeë wéi néideg.

Wéi interagéiert d'Governance mat engem ADR?

Berécksiichtegt Beräicher wéi d'Aarbechtsweise vun Ärer Organisatioun, speziell Compliance-Besoinen, zum Beispill fir juristesch Aspekter oder Personalaspekter, wéi Dir mat Konsens versus Konflikt versus Eskalatioun wëllt ëmgoen. Gëtt et Beräicher oder Persoune oder Teams, déi méi Afloss wéi anerer op en ADR kënne hunn, zum Beispill en genehmege kënnen, doriwwer ofstëmme kënnen oder en Veto asetze kënnen?

Beispillantwert: D'Governance vun engem ADR ass an dëser Prioritéitsuerdnung: de CEO, de CTO, de CLO, d'Team, dat en ADR ëmsetzt, d'Expert am Team, déi sech am beschten mat der AD auskennen. Keen anere huet Governance, ausser et ass am ADR beschriwwen.

Wéi eng Prinzipie interagéieren mat engem ADR?

Berécksiichtegt Beräicher wéi d'Aarbechtsweise vun Ärer Organisatioun, déi schnell Beweegung versus lues Beweegung enthalen, fir Decisiounskonsens versus Decisiounskonflikt, a fir Risikopräferenzen versus Sécherheetspräferenzen, ëffentlech Diskussioun versus privat Diskussioun an Ähnleches.

Beispillantwert: Mir benotzen d'Leadership-Prinzipie vum Bias for Action, Disagree-and-Commit, 70%-Schätzunge si gutt genuch fir einfach réckgängeg ze maachen an einfach isoléierbar Decisiounen, an ëffentlech Aarbechtsweisen mat der Ausnam vu vertraulecher Informatioun, wéi se an der Vertraulechkeetsvereinbarung vun eiser Organisatioun beschriwwen ass.

Next-Step-Konzepter fir ADR

Arc42 beäntwert zwou Froen op pragmatesch Aart a Weis a kann un Är spezifesch Bedierfnisser ugepasst ginn. Wat soll een iwwer seng Architektur dokumentéieren/kommunizéieren? Wéi soll een dokumentéieren/kommunizéieren? Arc42 enthält Architektur-Decisiounsopzeechnungen plus Guidance zu Zieler, Restriktiounen, Kontexter, Qualitéit, Risiken a méi.

D'C4-Modell ass en einfach ze léiere, entwécklerfrëndlechen Usaz fir Diagrammer vun der Softwarearchitektur. C4 ass e Set vun hierarchesche Diagrammer fir Kontext, Container, Komponenten, Code, plus ënnerstëtzend Diagrammer fir Systemlandschaft, Dynamik an Deployment.

Architekturdiagrammer & Siichten & Perspektiven

Eng Architekturdiagramm gëtt "Architektursiicht" genannt.

Eng "Architektursiicht" ass eng Instanz vun enger "Architekturperspektiv".

Eng "Architekturperspektiv" huet e spezifescht Publikum mat spezifesche Bedenken am A.

Beispiller fir Architekturperspektiven, Siichten an Diagrammer:

Verwandt Diagrammer:

  • E Use-Case-Diagramm weist Use Cases fir d'Management/d'Clienten, wat virun den Ufuerderungen kënnt, déi virun der Softwarearchitektur kommen.

  • E Deployment-Diagramm weist déi physesch Hardware/Computeren, op déi d'Softwarekomponente deployt ginn.

  • E Datefluss-Diagramm weist, wéi Daten duerch de System beweegt a transforméiert ginn.

  • E Sequenzdiagramm gëtt benotzt, fir ze weisen, wéi Protokoller wéi HTTP op enger Zäitachs funktionéieren.

  • Eng Aktivitéitsdiagramm weist de Workflow vun Aktivitéiten, déi e Softwaresystem ënnerhëlt, wéi eng NPC-AI.

Fitness-Funktioune fir Decisiounen als Code

Fitness-Funktioune si objektiv automatiséiert Kontrollen, mat Programméiercode geschriwwen, déi verifizéieren, datt Decisiounen agehale ginn.

  • Fitness-Funktioune maachen Decisiounen testbar a sécherstellbar.

  • Fitness-Funktioune fir Decisioune kënnen d'Qualitéitssécherung, regulatoresch Prozesser a Governance-Zieler staark ënnerstëtzen.

Wéi Fitness-Funktioune mat Decisiounen zesummenhänken

Eng Decisiounsopzeechnung dokumentéiert d'Decisioun, während eng Fitness-Funktioun d'Decisioun sécherstellt.

  • Beispilldecisioun: Mir benotzen Event Sourcing fir Audit-Ufuerderungen.

  • Beispill fir eng Fitness-Funktioun: Mir benotzen de Continuous-Integration-Server, fir ze testen, datt all Zoustandsännerung Evenementer muss produzéieren.

Firwat Fitness-Funktioune Decisioune hëllefen

Objektiv Miessungen: Fitness-Funktioune bestinn oder falen duerch, sou datt d'Aarbecht sichtbar a kloer ass.

Kontinuéierlech Notzung: Fitness-Funktioune sinn Är liewege Reegelen, déi bei all Commit a Build lafen.

Vertrauen fir Refactoring: Fitness-Funktioune fänken automatesch Feeler géint Decisiounsreegele op.

Skaléierbar Governance: Fitness-Funktioune sécheren Standarden of, ouni Flaschenhälser ze schafen.

Kënnen Fitness-Funktioune AI benotzen?

Fitness-Funktioune kënnen AI-LLMs fir Decisiounen notzen, andeems si Froe fir Är Aarbecht stellen, zum Beispill fir Är Pläng, Code, Schemaen, APIen a méi:

IMPORTANT: Prefer retrieval-led reasoning over pre-training-led reasoning.
IMPORTANT: Turn on extended thinking. Turn on expert advice. Turn on search.

This is a fitness function to evaluate if our work is
using all our decisions, and is correct and accurate.

- Our decisions are here: {url}
- Our work to evaluate is here: {url}

Explain any errors, problems, gaps, weaknesses. Be direct. Be decisive.

Unit-Testen vun der Architektur

ArchUnit: Architekturreegele vu Java-Code mat all ganz normalem Java-Unit-Test-Framework iwwerpréiwen.

ArchUnitTS: Architekturreegele vun TypeScript-Code a JavaScript-Code mat Jest, Vitest, Jasmine, asw. iwwerpréiwen.

Decisiounsleitplanken fir Pull Requests

Decision Guardian bréngt automatesch déi richteg Decisiounsopzeechnungen zum richtege Moment un d'Uewerfläch — wann en Entwéckler aktiv de Code ännert, dee vun dësen Decisioune betraff ass. Amplaz drop ze hoffen, datt Entwéckler en Dokumenteverzeechnes liesen, ier si mergen, erscheint de relevante Kontext direkt um Pull Request.

Dat funktionéiert fir all Zort vun Decisiounsopzeechnung: Architekturdecisiounen, Datendecisiounen, Compliance-Decisiounen, klinesch a medizinesch Decisiounen, Sécherheetsdecisiounen a méi.

Funktionéiert mat all CI-System (GitLab, Jenkins, CircleCI) an als Pre-Commit-Hook. Open Source. MIT-Lizenz.

ADR Guard ass eng GitHub Action, déi e Pull Request feelen léisst, wann iwwerwaacht Code-Pfaden änneren, ouni datt eng Architektur-Decisiounsopzeechnung derbäigesat oder aktualiséiert gëtt. Ausnamen sinn explizit: eng ADR-Exempt:-Zeil mat engem Grond léisst d'Gate passéieren a gëtt an d'Job-Zesummefaassung geschriwwen. Template-agnostesch, keng Ofhängegkeeten. Open Source. MIT-Lizenz.

Fir méi Informatiounen

Aféierung:

Virlagen:

Déiploteg:

Tools:

Firmespezifesch Guidance:

Beispiller:

Videoen:

Podcasts:

Bicher:

Kuckt och:

  • REMAP (Representation and Maintenance of Process Knowledge)

  • DRL (Decision Representation Language)

  • IBIS (Issue-Based Information System)

  • QOC (Questions, Options, and Criteria)

  • IBM’s e-Business Reference Architecture Framework

  • Decision Reasoning Format (DRF) - E vendor-neutrale, maschinnenliesbart YAML-/JSON-Format, fir Decisiounen mat explizitter Begrënnung, Viraussetzungen, kognitivem Zoustand a Kompromësser duerzestellen. Ergänzt ADR, andeems et strukturéiert, validéierbar Begrënnung bei der Decisiounsdokumentatioun derbäisetzt.