diff --git a/docs/adr/0000-record-architecture-decisions.md b/docs/adr/0000-record-architecture-decisions.md new file mode 100644 index 00000000..fcd64cce --- /dev/null +++ b/docs/adr/0000-record-architecture-decisions.md @@ -0,0 +1,16 @@ +# Record architecture decisions + +* Status: accepted +* Date: 2023-10-16 + +## Context + +We need to record the architectural decisions made on Opinionated Digital Center. + +## Decision + +We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions). + +## Consequences + +See Michael Nygard's article, linked above. diff --git a/docs/adr/0001-use-markdown-architectural-decision-records.md b/docs/adr/0001-use-markdown-architectural-decision-records.md new file mode 100644 index 00000000..2c99e241 --- /dev/null +++ b/docs/adr/0001-use-markdown-architectural-decision-records.md @@ -0,0 +1,43 @@ +# Use Markdown Architectural Decision Records + +Adapted from +[MADR's similar decision record](https://github.com/adr/madr/blob/2.1.2/docs/adr/0000-use-markdown-architectural-decision-records.md). + +* Status: accepted +* Date: 2023-10-16 + +## Context and Problem Statement + +We want to record architectural decisions made in this project. +Which format and structure should these records follow? + +## Considered Options + +* [MADR](https://adr.github.io/madr/) 3.0.0 - The Markdown Architectural Decision Records +* [Michael Nygard's template](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions) - The first incarnation of the term "ADR" +* [Sustainable Architectural Decisions](https://www.infoq.com/articles/sustainable-architectural-design-decisions) - The Y-Statements +* Other templates listed at +* Formless - No conventions for file format and structure + +## Decision Outcome + +Chosen option: "MADR 3.0.0", because + +* Implicit assumptions should be made explicit. + Design documentation is important to enable people understanding the decisions later on. + See also [A rational design process: How and why to fake it](https://doi.org/10.1109/TSE.1986.6312940). +* The MADR format is lean and fits our development style. +* The MADR structure is comprehensible and facilitates usage & maintenance. +* Version 3.0.0 is the latest one available when starting to document ADRs. + +### Positive Consequences + +The ADR are more structured. See especially: +* [MADR-0002 - Do not use numbers in headings](https://github.com/adr/madr/blob/2.1.2/docs/adr/0002-do-not-use-numbers-in-headings.md). +* [MADR-0005 - Use (unique number and) dashes in filenames](https://github.com/adr/madr/blob/2.1.2/docs/adr/0005-use-dashes-in-filenames.md). +* [MADR-0010 - Support categories (in form of subfolders with local ids)](https://github.com/adr/madr/blob/2.1.2/docs/adr/0010-support-categories.md). +* See [full set of MADR ADRs](https://github.com/adr/madr/blob/2.1.2/docs/adr). + +### Negative Consequences + +* Learning curve will be slightly longer. diff --git a/docs/adr/index.md b/docs/adr/index.md new file mode 100644 index 00000000..3754fe7c --- /dev/null +++ b/docs/adr/index.md @@ -0,0 +1,23 @@ + +# Architecture Decision Records + +## Accepted Records + +* [0000 - Record architecture decisions](0000-record-architecture-decisions.md) +* [0001 - Use Markdown Architectural Decision Records](0001-use-markdown-architectural-decision-records.md) + +## Rejected Records + +* None + +## Superseded Records + +* None + +## Deprecated Records + +* None + +## Records with non-standard statuses + +* None diff --git a/docs/adr/template.md b/docs/adr/template.md new file mode 100644 index 00000000..f4da6f8c --- /dev/null +++ b/docs/adr/template.md @@ -0,0 +1,79 @@ +--- +# These are optional elements. Feel free to remove any of them. +status: "{proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)}" +date: {YYYY-MM-DD when the decision was last updated} +deciders: {list everyone involved in the decision} +consulted: {list everyone whose opinions are sought (typically subject-matter experts); and with whom there is a two-way communication} +informed: {list everyone who is kept up-to-date on progress; and with whom there is a one-way communication} +--- +# {short title of solved problem and solution} + +## Context and Problem Statement + +{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. + You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.} + + +## Decision Drivers + +* {decision driver 1, e.g., a force, facing concern, …} +* {decision driver 2, e.g., a force, facing concern, …} +* … + +## Considered Options + +* {title of option 1} +* {title of option 2} +* {title of option 3} +* … + +## Decision Outcome + +Chosen option: "{title of option 1}", because +{justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}. + + +### Consequences + +* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …} +* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …} +* … + + +### Confirmation + +{Describe how the implementation of/compliance with the ADR is confirmed. E.g., by a review or an ArchUnit test. + Although we classify this element as optional, it is included in most ADRs.} + + +## Pros and Cons of the Options + +### {title of option 1} + + +{example | description | pointer to more information | …} + +* Good, because {argument a} +* Good, because {argument b} + +* Neutral, because {argument c} +* Bad, because {argument d} +* … + +### {title of other option} + +{example | description | pointer to more information | …} + +* Good, because {argument a} +* Good, because {argument b} +* Neutral, because {argument c} +* Bad, because {argument d} +* … + + +## More Information + +{You might want to provide additional evidence/confidence for the decision outcome here and/or + document the team agreement on the decision and/or + define when/how this decision the decision should be realized and if/when it should be re-visited. +Links to other decisions and resources might appear here as well.} \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index 007dc301..7e3f6186 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -165,6 +165,8 @@ extra_javascript: - javascripts/tablesort.js extra_css: - stylesheets/extra.css +exclude_docs: | + /adr/ watch: - docs - src