Showing preview only (829K chars total). Download the full file or copy to clipboard to get everything.
Repository: joelparkerhenderson/architecture-decision-record
Branch: main
Commit: a5c0ed4e8c54
Files: 453
Total size: 709.8 KB
Directory structure:
gitextract_2a7geaq3/
├── CITATION.cff
├── CODE_OF_CONDUCT.md
├── LICENSE.md
├── README.md
└── locales/
├── cy/
│ ├── .locale-peer-id
│ ├── nogfennau/
│ │ ├── .locale-peer-id
│ │ ├── awgrymiadau-ar-gyfer-ysgrifennu-adrs-da/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── beth-yw-cofnod-penderfyniad-pensaernïaeth/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── canllawiau-i-gyflawni-penderfyniadau-cynaliadwy/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── confensiynau-enw-ffeil/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cwestiynau-gwaith-tîm-ar-gyfer-adrau/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cyngor-gwaith-tîm-ar-gyfer-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── meini-prawf-cynaliadwyedd-penderfynu/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── proses-cofnodion-penderfynol-pensaernïol-aws/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── sut-i-ddechrau-defnyddio-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── sut-i-ddechrau-defnyddio-adrs-gyda-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── sut-i-ddechrau-defnyddio-adrs-gydag-offer/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── templedi/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── templed-cofnod-penderfyniad-ar-gyfer-achos-busnes/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-ar-gyfer-patrwm-alecsandraidd/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-jeff-tyree-and-art-akerman/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-planguage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── templed-cofnod-penderfyniad-y-prosiect-madr/
│ ├── .locale-peer-id
│ └── index.md
├── en/
│ ├── .locale-peer-id
│ ├── documents/
│ │ ├── .locale-peer-id
│ │ ├── aws-adr-process/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── decision-sustainability-criteria/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── file-name-conventions-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── fitness-functions-for-decisions-as-code/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── guidelines-to-achieve-sustainable-decisions/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-tools/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── suggestions-for-writing-good-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── teamwork-advice-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── teamwork-questions-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── what-is-an-architecture-decision-record/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── examples/
│ │ ├── .locale-peer-id
│ │ ├── 4-day-work-week/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── agile-software-development/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── amazon-web-services/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── api-using-json-v-grpc/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── authentication-authorization-options/
│ │ │ └── index.md
│ │ ├── browser-automation-framework-for-e2e-testing-playwright-vs-selenium/
│ │ │ └── index.md
│ │ ├── chart-library-toolkit-for-data-visualization-using-typescript-and-json/
│ │ │ └── index.md
│ │ ├── choosing-a-database-technology/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── continuous-integration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── css-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── docker-swarm-container-orchestration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── environment-variable-configuration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── go-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── google-cloud-platform/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── high-trust-teamwork/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── index.md
│ │ ├── java-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── kubernetes-container-orchestration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── metrics-monitors-alerts/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── microsoft-azure-cloud-infrastructure/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── microsoft-azure-devops/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── monorepo-vs-multirepo/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── mysql-database/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── postgresql-database/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── programming-code-editors/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── programming-languages/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── python-django-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── python-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── react-front-end-javascript-library/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── ruby-on-rails-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── rust-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── secrets-storage/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── snake-case-v-camelcase-for-a-rest-api/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── svelte-components/
│ │ │ └── index.md
│ │ ├── svelte-front-end-javascript-library/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── sveltekit-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── tailwind-css/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── timestamp-format/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── vue-front-end-javascript-library/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── web-application-framework-batteries-included-full-stack-for-a-startup-product/
│ │ │ └── index.md
│ │ └── work-from-home/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── templates/
│ ├── .locale-peer-id
│ ├── decision-record-template-by-arc42/
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-by-edgex/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-by-gareth-morgan/
│ │ ├── README.md
│ │ └── index.md
│ ├── decision-record-template-by-gig-cymru-nhs-wales/
│ │ └── index.md
│ ├── decision-record-template-by-jeff-tyree-and-art-akerman/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE-WIP.md
│ │ └── index.md
│ ├── decision-record-template-by-michael-nygard/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-for-alexandrian-pattern/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── decision-record-template-for-business-case/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── decision-record-template-of-the-madr-project/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-using-planguage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── index.md
├── es/
│ ├── .locale-peer-id
│ ├── documentos/
│ │ ├── .locale-peer-id
│ │ ├── consejo-de-trabajo-en-equipo-para-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── convenciones-de-nombre-de-archivo/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── criterios-de-sostenibilidad-de-decisión/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cómo-comenzar-a-usar-adr-con-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cómo-comenzar-a-usar-adr-con-herramientas/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cómo-comenzar-a-usar-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── directrices-para-lograr-decisiones-sostenibles/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── proceso-de-registros-de-decisiones-arquitectónicas-de-aws/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── qué-es-un-registro-de-decisión-de-arquitectura/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── sugerencias-para-escribir-buenos-adr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── plantillas/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── plantilla-de-registro-de-decisión-de-edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-de-jeff-tyree-y-art-akerman/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-de-michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-del-proyecto-madr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-para-caso-de-negocio/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-para-el-patrón-alejandrino/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── plantilla-de-registro-de-decisión-usando-planguage/
│ ├── .locale-directory-name-en.txt
│ ├── .locale-peer-id
│ └── index.md
├── fr/
│ ├── .locale-peer-id
│ ├── documents/
│ │ ├── .locale-peer-id
│ │ ├── comment-commencer-à-utiliser-les-adr/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── comment-commencer-à-utiliser-les-adr-avec-des-outils/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── comment-commencer-à-utiliser-les-adr-avec-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── conseils-de-travail-déquipe-pour-les-adr/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── conventions-de-noms-de-fichiers/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── critères-de-durabilité-de-décision/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── lignes-directrices-pour-atteindre-des-décisions-durables/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── processus-des-dossiers-de-décision-architecturale-aws/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── quest-ce-quun-dossier-de-décision-darchitecture/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── suggestions-pour-écrire-de-bonnes-adr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── modèles/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── modèle-denregistrement-de-décision par jeff-tyree-et-art-akerman/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision pour-lanalyse-de-rentabilisation/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision utilisant-plangage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision-du-projet-madr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision-par michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision-par-edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── modèle-denregistrement-de-décision-pour-le modèle-alexandrin/
│ ├── .locale-peer-id
│ └── index.md
├── index.md
├── ja/
│ ├── .locale-peer-id
│ ├── テンプレート/
│ │ ├── .locale-peer-id
│ │ ├── EdgeX Foundryによる意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── Jeff TyreeとArt Akermanによる意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── Michael Nygard による意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── Planguageを使用した意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── index.md
│ │ ├── madrプロジェクトの意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── アレクサンドリアパターンの意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── ビジネスケース用意思決定記録テンプレート/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── ドキュメント/
│ │ ├── .locale-peer-id
│ │ ├── aws-adr-process/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── decision-sustainability-criteria/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── file-name-conventions-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── guidelines-to-achieve-sustainable-decisions/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-tools/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── suggestions-for-writing-good-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── teamwork-advice-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── what-is-an-architecture-decision-record/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── 翻訳注.txt
├── ko/
│ ├── .locale-peer-id
│ ├── 서류/
│ │ ├── .locale-peer-id
│ │ ├── adr-사용을-시작하는-방법/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── adr을-위한-팀워크-조언/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── aws-아키텍처-결정-기록-프로세스/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── git에서-adr-사용을-시작하는-방법/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 도구를-사용하여-adr-사용을-시작하는-방법/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 아키텍처-결정-기록이란-무엇입니까/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 의사결정-지속가능성-기준/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 좋은-adr-작성을-위한-제안/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 지속-가능한-결정을-달성하기-위한-지침/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── 파일-이름-규칙/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── 템플릿/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── madr 프로젝트의 결정 기록 템플릿/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 결정 기록 템플릿별 edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 비즈니스 사례에 대한 의사결정 기록 템플릿/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 알렉산드리아 패턴에 대한 결정 기록 템플릿/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 의사 결정 기록 템플릿-by-michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 의사결정 기록 템플릿 사용 p언어/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── 의사결정 기록 템플릿-by-jeff-tyree-and-art-akerman/
│ ├── .locale-peer-id
│ └── index.md
└── tr/
├── .locale-peer-id
├── documents/
│ ├── .locale-peer-id
│ ├── aws-adr-process/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── decision-sustainability-criteria/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── file-name-conventions-for-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── guidelines-to-achieve-sustainable-decisions/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── how-to-start-using-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── how-to-start-using-adrs-with-git/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── how-to-start-using-adrs-with-tools/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── suggestions-for-writing-good-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── teamwork-advice-for-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── teamwork-questions-for-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── what-is-an-architecture-decision-record/
│ ├── .locale-peer-id
│ └── index.md
├── examples/
│ ├── .locale-peer-id
│ ├── 4-day-work-week/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── agile-software-development/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── amazon-web-services/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── api-using-json-v-grpc/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── authentication-authorization-options/
│ │ └── index.md
│ ├── browser-automation-framework-for-e2e-testing-playwright-vs-selenium/
│ │ └── index.md
│ ├── chart-library-toolkit-for-data-visualization-using-typescript-and-json/
│ │ └── index.md
│ ├── choosing-a-database-technology/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── continuous-integration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── css-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── docker-swarm-container-orchestration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── environment-variable-configuration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── go-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── google-cloud-platform/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── high-trust-teamwork/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── index.md
│ ├── java-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── kubernetes-container-orchestration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── metrics-monitors-alerts/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── microsoft-azure-cloud-infrastructure/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── microsoft-azure-devops/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── monorepo-vs-multirepo/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── mysql-database/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── postgresql-database/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── programming-code-editors/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── programming-languages/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── python-django-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── python-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── react-front-end-javascript-library/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── ruby-on-rails-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── rust-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── secrets-storage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── snake-case-v-camelcase-for-a-rest-api/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── svelte-components/
│ │ └── index.md
│ ├── svelte-front-end-javascript-library/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── sveltekit-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── tailwind-css/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── timestamp-format/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── vue-front-end-javascript-library/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── web-application-framework-batteries-included-full-stack-for-a-startup-product/
│ │ └── index.md
│ └── work-from-home/
│ ├── .locale-peer-id
│ └── index.md
└── templates/
├── .locale-peer-id
├── decision-record-template-by-arc42/
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-by-edgex/
│ ├── .locale-peer-id
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-by-gareth-morgan/
│ ├── README.md
│ └── index.md
├── decision-record-template-by-gig-cymru-nhs-wales/
│ └── index.md
├── decision-record-template-by-jeff-tyree-and-art-akerman/
│ ├── .locale-peer-id
│ ├── LICENSE-WIP.md
│ └── index.md
├── decision-record-template-by-michael-nygard/
│ ├── .locale-peer-id
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-for-alexandrian-pattern/
│ ├── .locale-peer-id
│ └── index.md
├── decision-record-template-for-business-case/
│ ├── .locale-peer-id
│ └── index.md
├── decision-record-template-of-the-madr-project/
│ ├── .locale-peer-id
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-using-planguage/
│ ├── .locale-peer-id
│ └── index.md
└── index.md
================================================
FILE CONTENTS
================================================
================================================
FILE: CITATION.cff
================================================
cff-version: 1.2.0
title: Architecture decision record (ADR)
message: >-
If you use this work and you want to cite it,
then you can use the metadata from this file.
type: software
authors:
- given-names: Joel Parker
family-names: Henderson
email: joel@joelparkerhenderson.com
affiliation: joelparkerhenderson.com
orcid: 'https://orcid.org/0009-0000-4681-282X'
identifiers:
- type: url
value: 'https://github.com/joelparkerhenderson/architecture-decision-record/'
description: Architecture decision record (ADR)
repository-code: 'https://github.com/joelparkerhenderson/architecture-decision-record/'
abstract: >-
Architecture decision record (ADR)
license: See license file
================================================
FILE: CODE_OF_CONDUCT.md
================================================
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, caste, color, religion, or sexual
identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall
community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of
any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address,
without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
[INSERT CONTACT METHOD].
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of
actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the
community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.1, available at
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
Community Impact Guidelines were inspired by
[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
For answers to common questions about this code of conduct, see the FAQ at
[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
[https://www.contributor-covenant.org/translations][translations].
[homepage]: https://www.contributor-covenant.org
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
[Mozilla CoC]: https://github.com/mozilla/diversity
[FAQ]: https://www.contributor-covenant.org/faq
[translations]: https://www.contributor-covenant.org/translations
================================================
FILE: LICENSE.md
================================================
# License
For the work that I've personally done, such as writing the README.md file, the license is CC BY-NC-SA.
https://creativecommons.org/licenses/by-nc-sa/4.0/
For the work that is included created by others, such as the original authors of
the templates, please see the original works for their respective licenses, and
optionally see each work's folder for a respective LICENSE.md file if available.
================================================
FILE: README.md
================================================
<!--
browser: architecture-decision-record
tracker: 2bd6622ec3beeeddd8ff55cf0ccf2efc
version: 3.2.0
updated: 2025-05-29T14:13:27Z
contact: Joel Parker Henderson (http://joelparkerhenderson.com)
options: commentable
summary: Architecture Decision Record (ADR) for software planning, CTO/CIO leadership teamwork, and project management documentation. Examples, templates, and tutorials.
tags: architecturedecisionrecord adr decisionrecord projectmanagement plan cto cio leadership teamwork documentation template tutorial architecture decision record
-->
# Architecture decision record (ADR)
An architecture decision record (ADR) is a document that captures an important architecture decision made along with its context and consequences.
Contents:
- [What is an architecture decision record?](#what-is-an-architecture-decision-record)
- [How to start using ADRs](#how-to-start-using-adrs)
- [How to start using ADRs with tools](#how-to-start-using-adrs-with-tools)
- [How to start using ADRs with git](#how-to-start-using-adrs-with-git)
- [File name conventions for ADRs](#file-name-conventions-for-adrs)
- [Suggestions for writing good ADRs](#suggestions-for-writing-good-adrs)
- [ADR example templates](#adr-example-templates)
- [Teamwork advice for ADRs](#teamwork-advice-for-adrs)
- [Teamwork questions for ADRs](#teamwork-questions-for-adrs)
- [Next step concepts for ADRs](#next-step-concepts-for-adrs)
- [Architecture diagrams \& views \& viewpoints](#architecture-diagrams--views--viewpoints)
- [Fitness functions for decisions as code](#fitness-functions-for-decisions-as-code)
- [Decision guardrails for pull requests](#decision-guardrails-for-pull-requests)
- [For more information](#for-more-information)
Templates:
- [Decision record template by Jeff Tyree and Art Akerman](locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/)
- [Decision record template by Michael Nygard](locales/en/templates/decision-record-template-by-michael-nygard/)
- [Decision record template by EdgeX](locales/en/templates/decision-record-template-by-edgex/)
- [Decision record template by arc42](locales/en/templates/decision-record-template-by-arc42/)
- [Decision record template for Alexandrian pattern](locales/en/templates/decision-record-template-for-alexandrian-pattern/)
- [Decision record template for business case](locales/en/templates/decision-record-template-for-business-case/)
- [Decision record template of the MADR project](locales/en/templates/decision-record-template-of-the-madr-project/)
- [Decision record template using Planguage](locales/en/templates/decision-record-template-using-planguage/)
- [Decision record template by Paulo Merson](https://github.com/pmerson/ADR-template)
- [Decision record template by Olaf Zimmermann](https://medium.com/olzzio/y-statements-10eb07b5a177)
- [Decision record template by Gareth Morgan](locales/en/templates/decision-record-template-by-gareth-morgan/)
- [Decision record template by GIG Cymru NHS Wales](locales/en/templates/decision-record-template-by-gig-cymru-nhs-wales/)
- [Translations into more languages](locales/)
Examples:
- [CSS framework](locales/en/examples/css-framework/)
- [Environment variable configuration](locales/en/examples/environment-variable-configuration/)
- [Metrics, monitors, alerts](locales/en/examples/metrics-monitors-alerts/)
- [Microsoft Azure DevOps](locales/en/examples/microsoft-azure-devops/)
- [Monorepo vs multirepo](locales/en/examples/monorepo-vs-multirepo/)
- [Programming languages](locales/en/examples/programming-languages/)
- [Secrets storage](locales/en/examples/secrets-storage/)
- [Timestamp format](locales/en/examples/timestamp-format/)
- [Many more...](locales/en/examples/)
[Translations into more languages](locales/)
<div class="include" data-path="locales/en/documents/what-is-an-architecture-decision-record">
## What is an architecture decision record?
An **architecture decision record** (ADR) is a document that captures an important architectural decision made along with its context and consequences.
An **architecture decision** (AD) is a software design choice that addresses a significant requirement.
An **architecture decision log** (ADL) is the collection of all ADRs created and maintained for a particular project (or organization).
An **architecturally-significant requirement** (ASR) is a requirement that has a measurable effect on a software system’s architecture.
All these are within the topic of **architecture knowledge management** (AKM).
The goal of this document is to provide a fast overview of ADRs, how to create them, and where to look for more information.
Abbreviations:
- **AD**: architecture decision
- **ADL**: architecture decision log
- **ADR**: architecture decision record
- **AKM**: architecture knowledge management
- **ASR**: architecturally-significant requirement
</div>
<div class="include" data-path="locales/en/documents/how-to-start-using-adrs">
## How to start using ADRs
To start using ADRs, talk with your teammates about these areas.
Decision identification:
- How urgent and how important is the AD?
- Does it have to be made now, or can it wait until more is known?
- Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification.
- Ideally maintain a decision todo list that complements the product todo list.
Decision making:
- A number of decision making techniques exist, both general ones and software architecture specific ones, for instance, dialogue mapping.
- Group decision making is an active research topic.
Decision enactment and enforcement:
- ADs are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it.
- Architecturally evident coding styles and code reviews that focus on architectural concerns and decisions are two related practices.
- ADs also have to be (re-)considered when modernizing a software system in software evolution.
Decision sharing (optional):
- Many ADs recur across projects.
- Hence, experiences with past decisions, both good and bad, can be valuable reusable assets when employing an explicit knowledge management strategy.
Decision documentation:
- Many templates and tools for decision capturing exist.
- See agile communities, e.g. M. Nygard's ADRs.
- See traditional software engineering and architecture design processes, e.g. table layouts suggested by IBM UMF and by Tyree and Akerman from CapitalOne.
For more:
- The steps above are adopted from the Wikipedia entry on [Architectural Decision](https://en.wikipedia.org/wiki/Architectural_decision)
</div>
<div class="include" data-path="locales/en/documents/how-to-start-using-adrs-with-tools">
## How to start using ADRs with tools
You can start using ADRs with tools any way you want.
For example:
- If you like using Google Drive and online editing, then you can create a Google Doc, or Google Sheet.
- If you like use source code version control, such as git, then you can create a file for each ADR.
- If you like using project planning tools, such as Atlassian Jira, then you can use the tool's planning tracker.
- If you like using wikis, such as MediaWiki, then you can create an ADR wiki.
</div>
<div class="include" data-path="locales/en/documents/how-to-start-using-ADRs-with-git">
## How to start using ADRs with git
If you like using git version control, then here is how we like to start using ADRs with git for a typical software project with source code.
Create a directory for ADR files:
```sh
$ mkdir adr
```
For each ADR, create a text file, such as `database.txt`:
```sh
$ vi database.txt
```
Write anything you want in the ADR. See the templates in this repository for ideas.
Commit the ADR to your git repo.
</div>
<div class="include" data-path="locales/en/documents/file-name-conventions-for-adrs">
## File name conventions for ADRs
If you choose to create your ADRs using typical text files, then you may want to come up with your own ADR file name convention.
We prefer to use a file name convention that has a specific format.
Examples:
- choose-database.md
- format-timestamps.md
- manage-passwords.md
- handle-exceptions.md
Our file name convention:
- The name has a present tense imperative verb phrase. This helps readability and matches our commit message format.
- The name uses lowercase and dashes (same as this repo). This is a balance of readability and system usability.
- The extension is markdown. This can be useful for easy formatting.
</div>
<div class="include" data-path="locales/en/documents/suggestions-for-writing-good-adrs">
## Suggestions for writing good ADRs
Characteristics of a good ADR:
- Rationale: Explain the reasons for doing the particular AD. This can include the context (see below), pros and cons of various potential choices, feature comparisons, cost/benefit discussions, and more.
- Specific: Each ADR should be about one AD, not multiple ADs.
- Timestamps: Identify when each item in the ADR is written. This is especially important for aspects that may change over time, such as costs, schedules, scaling, and the like.
- Immutable: Don't alter existing information in an ADR. Instead, amend the ADR by adding new information, or supersede the ADR by creating a new ADR.
Characteristics of a good "Context" section in an ADR:
- Explain your organization's situation and business priorities.
- Include rationale and considerations based on social and skills makeups of your teams.
- Include pros and cons that are relevant, and describe them in terms that align with your needs and goals.
Characteristics of good "Consequences" section in an ADR:
- Explain what follows from making the decision. This can include the effects, outcomes, outputs, follow ups, and more.
- Include information about any subsequent ADRs. It's relatively common for one ADR to trigger the need for more ADRs, such as when one ADR makes a big overarching choice, which in turn creates needs for more smaller decisions.
- Include any after-action review processes. It's typical for teams to review each ADR one month later, to compare the ADR information with what's happened in actual practice, in order to learn and grow.
A new ADR may take the place of a previous ADR:
- When an AD is made that replaces or invalidates a previous ADR, then a new ADR should be created
</div>
## ADR example templates
ADR example templates that we have collected on the net:
- [ADR template by Michael Nygard](locales/en/templates/decision-record-template-by-michael-nygard/) (simple and popular)
- [ADR template by Jeff Tyree and Art Akerman](locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/) (more sophisticated)
- [ADR template for Alexandrian pattern](locales/en/templates/decision-record-template-for-alexandrian-pattern/) (simple with context specifics)
- [ADR template for business case](locales/en/templates/decision-record-template-for-business-case/) (more MBA-oriented, with costs, SWOT, and more opinions)
- [ADR template of the Markdown Any Decision Records (MADR) project](locales/en/templates/decision-record-template-of-the-madr-project/) (both simple and elaborate version; the latter emphasizes options and their pros and cons)
- [ADR template using Planguage](locales/en/templates/decision-record-template-using-planguage/) (more quality assurance oriented)
<div class="include" data-path="locales/en/documents/teamwork-advice-for-adrs">
## Teamwork advice for ADRs
If you're considering using decision records with your team, then here's some advice that we've learned by working with many teams.
You have an opportunity to lead your teammates, by talking together about the "why", rather than mandating the "what". For example, decision records are a way for teams to think smarter and communicate better; decision records are not valuable if they're just an after-the-fact forced paperwork requirement.
Some teams much prefer the name "decisions" over the abbreviation "ADRs". When some teams use the directory name "decisions", then it's as if a light bulb turns on, and the team starts putting more information into the directory, such as vendor decisions, planning decisions, scheduling decisions, etc. All of these kinds of information can use the same template. We hypothesize that people learn faster with words ("decisions") over abbreviations ("ADRs"), and people are more motivated to write work-in-progress docs when the word "record" is removed, and also some developers and some managers dislike the word "architecture".
In theory, immutability is ideal. In practice, mutability has worked better for our teams. We insert the new info the existing ADR, with a date stamp, and a note that the info arrived after the decision. This kind of approach leads to a "living document" that we all can update. Typical updates are when we get information thanks to new teammates, or new offerings, or real-world results of our usages, or after-the-fact third-party changes such as vendor capabilities, pricing plans, license agreements, etc.
</div>
<div class="include" data-path="locales/en/documents/teamwork-questions-for-adrs">
## Teamwork questions for ADRs
### Who can create an ADR?
Consider areas such as specific people, or specific roles, or specific teams, or specific departments; also consider if there are people, or roles, or teams, or department that can commission an ADR, meaning they request one that someone else will author.
Example answer: Any person in our organization who has read the architecture decision record README page can propose an ADR, meaning the person can start writing it, and share it with the team.
### What justifies raising an ADR?
Consider areas such as your organization's team ways of working, your software system structure, cross-team coordination, long-term maintainability, external interfaces, who you want to benefit, and the like.
Example answer: We want to create an ADR when we want future developers to understand the “why” of what we're doing.
### What justifies not raising an ADR?
Consider areas such as decisions that are not about architecture, or are tiny such as minimal-risk or self-contained or single-developer, or are already fully covered elsewhere such as by standards or policies or documentation, or are temporary such as workarounds or proofs of concepts or orexperiments.
Example answer: We want to skip an ADR when a decision is limited in scope and time and risk and cost, or is already covered elsewhere.
### What is the lifecycle of an ADR?
Consider areas such as the creation process, research process, decisioning process, implementation process, and sunsetting process. Consider how to track the ADR lifecycle over time, such as how to move the ADR from one state to the next state, and also how to communicate this to stakeholders.
Example answer: We want an ADR to have five lifecycle stages: Initiating → Researching → Evaluating → Implementing → Maintaining → Sunsetting.
### What are criteria for lifecycle steps of an ADR?
Consider areas such as acceptance criteria for an ADR, meaning how do you know it's good enough to progress from one lifecycle step to the next? Is the problem clearly articulated? Have the alternatives been considered? Are trade-offs well-enough understood and documented?
Is all relevant context in place? Are all relevant stakeholders involved? Has all feedback been incorporated?
Example answer: We want an ADR to be voted on by stakeholders when the active team has 1) completed their research, 2) completed their evaluation, 3) published the ADR proposal to the stakeholders with a request for comments and a timebox of one week, 4) all stakeholder comments have been incorporated and addressed.
### What roles and responsibilities interact with an ADR?
Consider roles such as proposer, researcher, evaluator, reviewer, approver, maintainer, and the like. Consider responsibilities such as communication with stakeholders, ensuring expectations are met, sharing on the website or intranet, and reviewing the work periodically and especially when relevant changes happen.
Example answer: We want each ADR to always have a primary contact person, secondary contact person, and accountable team; these are responsible for communications, publications, maintenance, periodic review at least once per year, and eventual sunsetting as needed.
### How does governance interact with an ADR?
Consider areas such as your organization's ways of working, any special compliance needs such as for legal aspects or human resource aspects, how you want to handle consensus versus conflict versus escalation. Are there areas or people or teams that can have more influence than others regarding an ADR, such as being able to approve it, or vote on it, or veto it?
Example answer: The governance of an ADR is in this priority order: the CEO, the CTO, the CLO, the team that implements an ADR, the experts on the team that are most-knowledgeable about the AD. No one else has governance unless described in the ADR.
### What principles interact with an ADR?
Consider areas such as your organization's ways of working that include moving quickly versus moving slowly, for decision consensus versus decision conflict, and for risk preferences versus safety preferences, public discussion versus private discussion, and the like.
Example answer: We use the leadership principles of bias for action, disagree-and-commit, 70% estimates are good enough for easily-reversable easily-isolatable decisions, and public ways of working with the exception of confidential information as described in our organization's confidentiality agreement.
</div>
<div class="include" data-path="locales/en/documents/next-step-concepts-for-adrs">
## Next step concepts for ADRs
[Arc42](https://arc42.org/) answers two questions in a pragmatic way and can be tailored to your specific needs. What should you document/communicate about your architecture? How should you document/communicate? Arc42 includes architecture decision records plus guidance on goals, constraints, contexts, quality, risks, and more.
[The C4 model](https://c4model.com/) is an easy to learn, developer friendly approach to software architecture diagramming. C4 is a set of hierarchical digrams for context, containers, components, code, plus supporting diagrams for system landscape, dynamic, and deployment.
</div>
<div class="include" data-path="locales/en/documents/architecture-diagrams-views-viewpoints">
## Architecture diagrams & views & viewpoints
An architecture diagram is called an "architecture view".
An "architecture view" is an instance of a "architecture viewpoint".
An "architecture viewpoint" has a specific audience with specific concerns in mind.
Architecture viewpoint examples, view examples, and diagram examples:
- Business Capabilities
- High-level Business Processes
- [Value Streams](https://en.wikipedia.org/wiki/Value_stream)
- Software Functions mapped to application components
- [C4 Model](https://en.wikipedia.org/wiki/C4_model) Context Diagram (TO-BE / AS-IS)
- [C4 Model](https://en.wikipedia.org/wiki/C4_model) Container Diagram (TO-BE / AS-IS)
- [Entity-relationship Diagram](https://en.wikipedia.org/w/index.php?title=Entity_relationship_diagram) (ERD) to map data entities to application components
- [Sequence Diagrams](https://en.wikipedia.org/wiki/Sequence_diagram) to describe functional flows within systems and for integrations
- [Business Process Model and Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) (BPMN) diagrams to describe data flows across application components
- [Business Process Model and Notation](https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation) (BPMN) diagrams to describe business processes / user Scenarios
- [Identity and Access Management](https://en.wikipedia.org/wiki/Identity_and_access_management) (IAM) diagrams
- [Role-Based Access Control](https://en.wikipedia.org/wiki/Role-based_access_control) (RBAC) diagrams with roles per application component
- [Attribute-Based Access Control](https://en.wikipedia.org/wiki/Attribute-based_access_control) (ABAC) diagrams with attributes per application component
- Privacy diagrams
Related diagrams:
- A Use Case Diagram shows use cases to management/customers, which precedes requirements, which precedes the software architecture.
- A Deployment Diagram shows the physical hardware/computers that the software components are deployed to.
- A Data Flow Diagram shows how data moves through the system and is transformed.
- A Sequence Diagram is used to show how protocols like HTTP work on a time axis.
- An Activity Diagram depicts the workflow of activities a software system undertakes, like an NPC AI.
<div class="include" data-path="locales/en/documents/fitness-functions-for-decisions-as-code">
## Fitness functions for decisions as code
Fitness functions are objective automated checks, written with programming code, that verify decisions are being maintained.
- Fitness functions make decisions testable and assurable.
- Fitness functions for decisions can greatly help quality assurance, regulatory processes, and governance goals.
### How fitness functions connect to decisions
A decision record documents the decision, while a fitness function assures the decision.
- Example decision: We use event sourcing for audit requirements.
- Example fitness function: We use the continuous integration server to test that all state changes must produce events.
### Why fitness functions help decisions
Objective measurements: Fitness functions pass or fail, so work is visible and clear.
Continuous use: Fitness functions are your living rules, run on every commit and build.
Confidence to refactor: Fitness functions automatically catch decision rule errors.
Scalable governance: Fitness functions assure standards without creating bottlenecks.
### Can fitness functions use AI?
Fitness functions can leverage AI LLMs for decisions by asking questions for your work,
such as your plans, code, schemas, APIs, and more:
```txt
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 wor to evaluate is here: {url}
Explain any errors, problems, gaps, weaknesses. Be direct. Be decisive.
```
### Architecture unit testing
[ArchUnit](https://www.archunit.org/): check architecture rules of Java code by using any plain Java unit test framework.
[ArchUnitTS](https://github.com/LukasNiessen/ArchUnitTS): check architecture rules of TypeScript code and JavaScript code by using Jest, Vitest, Jasmine, etc.
## Decision guardrails for pull requests
[Decision Guardian](https://github.com/DecispherHQ/decision-guardian)
automatically surfaces the right decision records at the right moment — when a
developer is actively modifying the code those decisions cover. Instead of
hoping developers read a docs folder before merging, the relevant context
appears directly on the pull request.
This works for any kind of decision record: architecture decisions, data
decisions, compliance decisions, clinical and medical decisions, security
decisions, and more.
Works with any CI system (GitLab, Jenkins, CircleCI) and as a pre-commit hook.
Open source. MIT license.
## For more information
Introduction:
- [Architectural decision (wikipedia.org)](https://wikipedia.org/wiki/Architectural_decision)
- [Architecturally significant requirements (wikipedia.org)](https://wikipedia.org/wiki/Architecturally_significant_requirements)
Templates:
- [Documenting architecture decisions - Michael Nygard (thinkrelevance.com)](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions)
- [Markdown Architectural Decision Records (adr.github.io)](https://adr.github.io/madr/)
- [Template for documenting architecture alternatives and decisions (stackoverflow.com)](http://stackoverflow.com/questions/7104735/template-for-documenting-architecture-alternatives-and-decisions)
In-depth:
- [ADMentor XML project (github.com)](https://github.com/IFS-HSR/ADMentor)
- [Architectural Decision Guidance across Projects: Problem Space Modeling, Decision Backlog Management and Cloud Computing Knowledge (ifs.hsr.ch)](https://www.ifs.hsr.ch/fileadmin/user_upload/customers/ifs.hsr.ch/Home/projekte/ADMentor-WICSA2015ubmissionv11nc.pdf)
- [The Decision View's Role in Software Architecture Practice (computer.org)](https://www.computer.org/csdl/mags/so/2009/02/mso2009020036-abs.html)
- [Documenting Software Architectures: Views and Beyond (resources.sei.cmu.edu)](http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=30386)
- [Architecture Decisions: Demystifying Architecture (utdallas.edu)](https://www.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions-tyree-05.pdf)
- [ThoughtWorks Technology Radar: Lightweight Architecture Decision Records (thoughtworks.com)](https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records)
- [A Skeptic’s Guide to Software Architecture Decisions (infoq.com)](https://www.infoq.com/articles/architecture-skeptics-guide/)
- [Architectural Decisions — The Making Of](https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html)
- [Architectural Retrospectives: the Key to Getting Better at Architecting](https://www.infoq.com/articles/architectural-retrospectives/)
- [Software Architecture Monday with Mark Richards](https://developertoarchitect.com/lessons/) - free monthly software architecture lesson
- [Solution Architecture Decisions - By Gareth Morgan](https://www.linkedin.com/pulse/solution-architecture-decisions-gareth-morgan-0r5xe/)
Tools:
- [Command-line tools for working with Architecture Decision Records](https://github.com/npryce/adr-tools)
- [Command line tools with python - by Victor Sluiter](https://bitbucket.org/tinkerer_/adr-tools-python/src/master/)
- [Architectural Design Decision Support Framework (ADvISE)](https://swa.univie.ac.at/Software_Architecture/research-projects/architectural-design-decision-support-framework-advise/)
- [Decision Guardian](https://github.com/DecispherHQ/decision-guardian)
Company-Specific Guidance:
- [Amazon: AWS Prescriptive Guidance: ADR Process](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html)
- [GitHub: ADR GitHub organization](https://adr.github.io/)
- [RedHat: Why you should use ADRs](https://www.redhat.com/architect/architecture-decision-records)
Examples:
- [Repository of Architecture Decision Records made for the Arachne Framework](https://github.com/arachne-framework/architecture)
Videos:
- [An introduction to arc42 with Savvas Kleanthous](https://www.youtube.com/watch?v=V5clR8c6D7o)
- [The C4 model for visualising software architecture - by Simon Brown](https://www.youtube.com/watch?v=KvoBrUd1-5E)
Podcasts:
- [Software Architecture Bookclub Podcast](https://www.developertoarchitect.com/bookclub-podcast.html)
Books:
- [Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture - by Christian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling and Carola Lilienthal](https://www.amazon.com/Software-Architecture-Metrics-Christian-Ciceri-ebook/dp/B0B1NZ8Z5V)
- [Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives - by Nick Rozanski and Eoin Woods](https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/032171833X)
- [Software Architecture in Practice (SEI Series in Software Engineering)](https://www.amazon.com/Software-Architecture-Practice-SEI-Engineering-ebook/dp/B094CPJ96B)
- [Documenting Software Architectures: Views and Beyond (SEI Series in Software Engineering)](https://www.amazon.com/Documenting-Software-Architectures-Beyond-Engineering-ebook/dp/B0046XS3RO)
- [The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise](https://www.amazon.com/Software-Architect-Elevator-Redefining-Architects-ebook/dp/B086WQ9XL1)
- [Fundamentals of Software Architecture: An Engineering Approach - by Mark Richards and Neal Ford](https://www.amazon.com/Fundamentals-Software-Architecture-Engineering-Approach-ebook/dp/B0849MPK73)
- [Building Evolutionary Architectures - by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage](https://www.amazon.com/Building-Evolutionary-Architectures-Neal-Ford-ebook/dp/B0BN4T1P27?crid=37FA31IFLAS0Z)
- [Foundations of Decision Analysis by Ronald Howard and Ali Abbas](https://www.amazon.com/Foundations-Decision-Analysis-Ronald-Howard-ebook/dp/B00SZECJTI?crid=14BK5SDP76UN6)
- [Head First Software Architecture - by Raju Gandhi, Neal Ford and Mark Richards](https://www.amazon.com/Head-First-Software-Architecture-Architectural-ebook/dp/B0CW1JMNF2)
- [Communication Patterns: A Guide for Developers and Architects - by Jacqui Read](https://www.amazon.com/Communication-Patterns-Guide-Developers-Architects/dp/1098140540)
See also:
- 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)](https://github.com/reasoning-formats/reasoning-formats) - A vendor-neutral, machine-readable YAML/JSON format for representing decisions with explicit reasoning, assumptions, cognitive state, and trade-offs. Complements ADRs by adding structured, validatable reasoning to decision documentation.
================================================
FILE: locales/cy/.locale-peer-id
================================================
0b59cb46e5817b414866ebe33f4d7bcf
================================================
FILE: locales/cy/nogfennau/.locale-peer-id
================================================
abc7c72d426bc75e40b25a44ae37ce73
================================================
FILE: locales/cy/nogfennau/awgrymiadau-ar-gyfer-ysgrifennu-adrs-da/.locale-peer-id
================================================
dc1a294e76821d6d3b086a2b17988427
================================================
FILE: locales/cy/nogfennau/awgrymiadau-ar-gyfer-ysgrifennu-adrs-da/index.md
================================================
## Awgrymiadau ar gyfer ysgrifennu ADRs da
Nodweddion ADR da:
* Rhesymeg: Esboniwch y rhesymau dros wneud yr hysbyseb benodol. Gall hyn gynnwys cyd -destun (gweler isod), manteision ac anfanteision amrywiol ddewisiadau posib, cymhariadau nodwedd, trafodaethau cost/budd, a mwy.
* Penodol: Dylai pob ADR fod tua un hysbyseb, nid hysbysebion lluosog.
* Timestamps: Nodwch pryd mae pob eitem yn yr ADR wedi'i hysgrifennu. Mae hyn yn arbennig o bwysig ar gyfer agweddau a allai newid dros amser, megis costau, amserlenni, graddio, ac ati.
* Na ellir ei symud: Peidiwch â newid y wybodaeth bresennol mewn ADR. Yn lle hynny, diwygiwch yr ADR trwy ychwanegu gwybodaeth newydd, neu ddisodli'r ADR trwy greu ADR newydd.
Nodweddion adran "cyd -destun" dda mewn ADR:
* Esboniwch sefyllfa a blaenoriaethau busnes eich sefydliad.
* Cynhwyswch resymeg ac ystyriaethau yn seiliedig ar golurion cymdeithasol a sgiliau eich timau.
* Cynhwyswch fanteision ac anfanteision sy'n berthnasol, a'u disgrifio mewn termau sy'n cyd -fynd â'ch anghenion a'ch nodau.
Nodweddion adran "Canlyniadau" da mewn ADR:
* Esboniwch beth sy'n dilyn o wneud y penderfyniad. Gall hyn gynnwys yr effeithiau, canlyniadau, allbynnau, gwaith dilynol, a mwy.
* Cynhwyswch wybodaeth am unrhyw ADRs dilynol. Mae'n gymharol gyffredin i un ADR sbarduno'r angen am fwy o ADRs, megis pan fydd un ADR yn gwneud dewis trosfwaol mawr, sydd yn ei dro yn creu anghenion am benderfyniadau mwy llai.
* Cynhwyswch unrhyw brosesau adolygu ar ôl gweithredu. Mae'n nodweddiadol i dimau adolygu pob ADR fis yn ddiweddarach, i gymharu'r wybodaeth ADR â'r hyn sydd wedi digwydd mewn ymarfer gwirioneddol, er mwyn dysgu a thyfu.
Gall ADR newydd gymryd lle ADR blaenorol:
* Pan wneir hysbyseb sy'n disodli neu'n annilysu ADR blaenorol, yna dylid creu ADR newydd
================================================
FILE: locales/cy/nogfennau/beth-yw-cofnod-penderfyniad-pensaernïaeth/.locale-peer-id
================================================
020ff535ed1a3347a265209291e756b6
================================================
FILE: locales/cy/nogfennau/beth-yw-cofnod-penderfyniad-pensaernïaeth/index.md
================================================
## Beth yw cofnod penderfyniad pensaernïaeth?
Mae Cofnod Penderfyniad Pensaernïaeth ** ** (ADR) yn ddogfen sy'n cyfleu penderfyniad pensaernïol pwysig a wnaed ynghyd â'i gyd -destun a'i ganlyniadau.
Mae Penderfyniad Pensaernïaeth ** ** (AD) yn ddewis dylunio meddalwedd sy'n mynd i'r afael â gofyniad sylweddol.
Log Penderfyniad Pensaernïaeth ** ** (ADL) yw'r casgliad o'r holl ADRs a grëwyd ac a gynhelir ar gyfer prosiect (neu sefydliad) penodol.
Mae gofyniad pensaernïol arwyddocaol ** (ASR) yn ofyniad sy'n cael effaith fesuradwy ar bensaernïaeth system feddalwedd.
Mae'r rhain i gyd o fewn pwnc ** Rheoli Gwybodaeth Pensaernïaeth ** (AKM).
Nod y ddogfen hon yw darparu trosolwg cyflym o ADRs, sut i'w creu, a ble i chwilio am ragor o wybodaeth.
Byrfoddau:
*** AD **: Penderfyniad Pensaernïaeth
*** ADL **: log penderfyniad pensaernïaeth
*** ADR **: cofnod penderfyniad pensaernïaeth
*** AKM **: Rheoli Gwybodaeth Bensaernïaeth
*** ASR **: gofyniad pensaernïol arwyddocaol
================================================
FILE: locales/cy/nogfennau/canllawiau-i-gyflawni-penderfyniadau-cynaliadwy/.locale-peer-id
================================================
934d1c42a693fe004cd8bf8f5ecb97e6
================================================
FILE: locales/cy/nogfennau/canllawiau-i-gyflawni-penderfyniadau-cynaliadwy/index.md
================================================
# Canllawiau i gyflawni penderfyniadau cynaliadwy
<https://www.infoq.com/articles/sustainable-architectural-design-decisions/>
Fe wnaethon ni ddysgu'r gwersi canlynol yn ein gwaith a all wasanaethu fel canllawiau ac asesiad ar gyfer cyflawni penderfyniadau cynaliadwy:
1. Defnyddiwch ddull main/minimalaidd ar gyfer y ddogfennaeth penderfyniad cychwynnol.
2. Blaenoriaethu a dal yr holl benderfyniadau pwysig sy'n ddigon perthnasol ar gyfer dogfennu a deall y bensaernïaeth darged.
3. Manylion y penderfyniadau arbennig o bwysig gyda thempledi wedi'u chwythu'n llawn dim ond ar ôl i'r gwaith cychwynnol gael ei wneud (hynny yw, pan fydd y rhai sy'n gwneud penderfyniadau yn fodlon â'r penderfyniadau pensaernïol a wnaed ac yn hyderus nad oes rhaid i'r penderfyniadau hyn gael eu hadolygu ar unrhyw adeg yn fuan ).
4. Defnyddiwch y fersiynau heb lawer o fraster/minimalaidd o Gam 1 fel fersiwn fer o benderfyniadau wedi'u dogfennu gyda'r lefel gronynnedd gywir i ddarparu trosolwg o'r penderfyniadau manwl, yn ogystal ag ar gyfer penderfyniadau dibwys neu amlwg.
5. Lle bynnag y bo hynny'n bosibl, defnyddiwch wybodaeth bensaernïol bresennol, naill ai o fodelau canllaw neu o ffynonellau eraill. Adolygu ac ymestyn gwybodaeth o'r fath a'i ffitio i gyd -destun y penderfyniad penodol.
6. Sicrhewch fod cysylltiadau olrhain yn cael eu sefydlu rhwng penderfyniadau a gofynion a dyluniadau/cod pensaernïol.
7. Darparu gwirio cysondeb awtomataidd i sicrhau bod y cysylltiadau olrhain mewn sync ar ôl newid. Cyfyngu ar nifer y dibyniaethau rhwng penderfyniadau ac arteffactau meddalwedd eraill.
8 Cymhwyso'r canllawiau ar gyfer y cyfiawnhad o ganlyniad ac yn rymus - dyna ran bwysicaf y ddogfennaeth benderfynu oherwydd eu bod yn rhoi'r rhesymeg.
================================================
FILE: locales/cy/nogfennau/confensiynau-enw-ffeil/.locale-peer-id
================================================
89116b5647aa1e53186f3c44b5a284a0
================================================
FILE: locales/cy/nogfennau/confensiynau-enw-ffeil/index.md
================================================
# Confensiynau Enw Ffeil
Os dewiswch greu eich ADRs gan ddefnyddio ffeiliau testun nodweddiadol, yna efallai yr hoffech feddwl am eich Confensiwn Enw Ffeil ADR eich hun.
Mae'n well gennym ddefnyddio confensiwn enw ffeil sydd â fformat penodol.
Enghreifftiau:
* dewiswch-database.md
* format-timestamps.md
* rheoli-passwords.md
* trin-exceptions.md
Ein Confensiwn Enw Ffeil:
* Mae gan yr enw ymadrodd berf hanfodol amser presennol. Mae hyn yn helpu darllenadwyedd ac yn cyd -fynd â'n fformat neges ymrwymo.
* Mae'r enw'n defnyddio llythrennau bach a rhuthrau (yr un fath â'r repo hwn). Mae hwn yn gydbwysedd o ddarllenadwyedd a defnyddioldeb system.
* Mae'r estyniad yn marcio. Gall hyn fod yn ddefnyddiol ar gyfer fformatio hawdd.
================================================
FILE: locales/cy/nogfennau/cwestiynau-gwaith-tîm-ar-gyfer-adrau/.locale-peer-id
================================================
60057747e4547af35fd888021e41f332
================================================
FILE: locales/cy/nogfennau/cwestiynau-gwaith-tîm-ar-gyfer-adrau/index.md
================================================
## Cwestiynau gwaith tîm ar gyfer ADRau
### Pwy all greu ADR?
Ystyriwch feysydd fel pobl benodol, neu rolau penodol, neu dimau penodol, neu adrannau penodol; ystyriwch hefyd a oes pobl, neu rolau, neu dimau, neu adran a all gomisiynu ADR, sy'n golygu eu bod yn gofyn am un y bydd rhywun arall yn ei awduro.
Ateb enghreifftiol: Gall unrhyw berson yn ein sefydliad sydd wedi darllen tudalen README cofnod penderfyniad pensaernïaeth gynnig ADR, sy'n golygu y gall y person ddechrau ei ysgrifennu, a'i rannu gyda'r tîm.
### Beth sy'n cyfiawnhau codi ADR?
Ystyriwch feysydd fel ffyrdd gweithio tîm eich sefydliad, strwythur eich system feddalwedd, cydlynu traws-dîm, cynaladwyedd hirdymor, rhyngwynebau allanol, pwy rydych chi am iddo fod o fudd, a'r cyffelyb.
Ateb enghreifftiol: Rydym am greu ADR pan fyddwn am i ddatblygwyr y dyfodol ddeall y "pam" dros yr hyn rydym yn ei wneud.
### Beth sy'n cyfiawnhau peidio â chodi ADR?
Ystyriwch feysydd fel penderfyniadau nad ydynt yn ymwneud â phensaernïaeth, neu sy'n fach fel risg leiaf neu hunangynhwysol neu ddatblygwr sengl, neu sydd eisoes wedi'u cynnwys yn llawn mewn mannau eraill fel gan safonau neu bolisïau neu ddogfennaeth, neu sy'n dros dro fel atebion dros dro neu brofion o gysyniadau neu arbrofion.
Ateb enghreifftiol: Rydym am hepgor ADR pan fo penderfyniad yn gyfyngedig o ran cwmpas ac amser a risg a chost, neu pan fydd eisoes wedi'i gynnwys mewn mannau eraill.
### Beth yw cylch bywyd ADR?
Ystyriwch feysydd fel y broses greu, y broses ymchwil, y broses benderfynu, y broses weithredu, a'r broses machlud. Ystyriwch sut i olrhain cylch bywyd yr ADR dros amser, fel sut i symud yr ADR o un cyflwr i'r cyflwr nesaf, a hefyd sut i gyfleu hyn i randdeiliaid.
Ateb enghreifftiol: Rydym am i ADR gael cam cylch bywyd: Cychwyn → Ymchwilio → Gwerthuso → Gweithredu → Cynnal → Machlud.
### Beth yw'r meini prawf ar gyfer camau cylch bywyd ADR?
Ystyriwch feysydd fel meini prawf derbyn ar gyfer ADR, sy'n golygu sut ydych chi'n gwybod ei fod yn ddigon da i symud ymlaen o un cam cylch bywyd i'r nesaf? A yw'r broblem wedi'i mynegi'n glir? A yw'r dewisiadau amgen wedi'u hystyried? A yw cyfaddawdau wedi'u deall a'u dogfennu'n ddigon da?
A yw'r holl gyd-destun perthnasol ar waith? A yw'r holl randdeiliaid perthnasol wedi'u cynnwys? A yw'r holl adborth wedi'i ymgorffori?
Ateb enghreifftiol: Rydym am i randdeiliaid bleidleisio ar ADR pan fydd y tîm gweithredol wedi 1) cwblhau eu hymchwil, 2) cwblhau eu gwerthusiad, 3) cyhoeddi'r cynnig ADR i'r rhanddeiliaid gyda chais am sylwadau ac amserlen o un wythnos, 4) bod yr holl sylwadau gan randdeiliaid wedi'u hymgorffori a'u trin.
### Pa rolau a chyfrifoldebau sy'n rhyngweithio ag ADR?
Ystyriwch rolau fel cynigydd, ymchwilydd, gwerthuswr, adolygydd, cymeradwywr, cynhaliwr, a'r fel. Ystyriwch gyfrifoldebau fel cyfathrebu â rhanddeiliaid, sicrhau bod disgwyliadau'n cael eu bodloni, rhannu ar y wefan neu'r fewnrwyd, ac adolygu'r gwaith yn rheolaidd ac yn enwedig pan fydd newidiadau perthnasol yn digwydd.
Ateb enghreifftiol: Rydym am i bob ADR gael prif berson cyswllt, ail berson cyswllt, a thîm atebol bob amser; mae'r rhain yn gyfrifol am gyfathrebu, cyhoeddiadau, cynnal a chadw, adolygiad cyfnodol o leiaf unwaith y flwyddyn, a'i machlud yn y pen draw yn ôl yr angen.
### Sut mae llywodraethu'n rhyngweithio ag ADR?
Ystyriwch feysydd fel ffyrdd gweithio eich sefydliad, unrhyw anghenion cydymffurfio arbennig fel ar gyfer agweddau cyfreithiol neu agweddau adnoddau dynol, sut rydych chi am ymdrin â chonsensws yn erbyn gwrthdaro yn erbyn dwysáu. A oes meysydd neu bobl neu dimau a all gael mwy o ddylanwad nag eraill ynghylch ADR, fel gallu ei gymeradwyo, neu bleidleisio arno, neu ei feto?
Ateb enghreifftiol: Mae llywodraethu ADR yn y drefn flaenoriaeth hon: y Prif Swyddog Gweithredol, y Prif Swyddog Technoleg, y Prif Swyddog Cyswllt, y tîm sy'n gweithredu ADR, yr arbenigwyr yn y tîm sydd fwyaf gwybodus am yr ADD. Nid oes gan unrhyw un arall lywodraethu oni bai ei fod wedi'i ddisgrifio yn y ADR.
### Pa egwyddorion sy'n rhyngweithio ag ADR?
Ystyriwch feysydd fel ffyrdd gweithio eich sefydliad sy'n cynnwys symud yn gyflym yn erbyn symud yn araf, ar gyfer consensws penderfyniadau yn erbyn gwrthdaro penderfyniadau, ac ar gyfer dewisiadau risg yn erbyn dewisiadau diogelwch, trafodaeth gyhoeddus yn erbyn trafodaeth breifat, a'r cyffelyb.
Ateb enghreifftiol: Rydym yn defnyddio egwyddorion arweinyddiaeth rhagfarn ar gyfer gweithredu, anghytuno ac ymrwymo, mae amcangyfrifon o 70% yn ddigon da ar gyfer penderfyniadau y gellir eu gwrthdroi'n hawdd ac y gellir eu hynysu'n hawdd, a ffyrdd cyhoeddus o weithio ac eithrio gwybodaeth gyfrinachol fel y disgrifir yng nghytundeb cyfrinachedd ein sefydliad.
================================================
FILE: locales/cy/nogfennau/cyngor-gwaith-tîm-ar-gyfer-adrs/.locale-peer-id
================================================
875a7715e592ceb45eac5e155ee16318
================================================
FILE: locales/cy/nogfennau/cyngor-gwaith-tîm-ar-gyfer-adrs/index.md
================================================
# Cyngor gwaith tîm ar gyfer ADRs
Os ydych chi'n ystyried defnyddio cofnodion penderfyniadau gyda'ch tîm, yna dyma ychydig o gyngor rydyn ni wedi'i ddysgu trwy weithio gyda llawer o dimau.
Mae gennych gyfle i arwain eich cyd -chwaraewyr, trwy siarad gyda'i gilydd am y "pam", yn hytrach na gorfodi'r "beth". Er enghraifft, mae cofnodion penderfyniadau yn ffordd i dimau feddwl yn ddoethach a chyfathrebu'n well; Nid yw cofnodion penderfyniadau yn werthfawr os mai dim ond gofyniad gwaith papur gorfodol ar ôl y ffaith ydyn nhw.
Mae'n well gan rai timau'r enw "penderfyniadau" dros y talfyriad "ADRS". Pan fydd rhai timau'n defnyddio'r enw cyfeiriadur "penderfyniadau", yna mae fel petai bwlb golau yn troi ymlaen, ac mae'r tîm yn dechrau rhoi mwy o wybodaeth yn y cyfeiriadur, megis penderfyniadau gwerthwr, penderfyniadau cynllunio, penderfyniadau amserlennu, ac ati. Mae'r holl fathau hyn o Gall gwybodaeth ddefnyddio'r un templed. Rydym yn damcaniaethu bod pobl yn dysgu'n gyflymach gyda geiriau ("penderfyniadau") dros fyrfoddau ("ADRs"), ac mae pobl yn fwy cymhelliant i ysgrifennu docs gwaith ar y gweill pan fydd y gair "record" yn cael ei dynnu, a hefyd rhai datblygwyr a rhai rheolwyr Ddim yn hoffi'r gair "pensaernïaeth".
Mewn theori, mae anfarwoldeb yn ddelfrydol. Yn ymarferol, mae treiglad wedi gweithio'n well i'n timau. Rydym yn mewnosod y wybodaeth newydd yr ADR presennol, gyda stamp dyddiad, a nodyn bod y wybodaeth wedi cyrraedd ar ôl y penderfyniad. Mae'r math hwn o ddull yn arwain at "ddogfen fyw" y gallwn ni i gyd ei diweddaru. Diweddariadau nodweddiadol yw pan gawn wybodaeth diolch i gyd-chwaraewyr newydd, neu offrymau newydd, neu ganlyniadau'r byd go iawn o'n defnyddiau, neu newidiadau trydydd parti ar ôl y ffaith fel capabilties gwerthwyr, cynlluniau prisio, cytundebau trwydded, ac ati.
================================================
FILE: locales/cy/nogfennau/meini-prawf-cynaliadwyedd-penderfynu/.locale-peer-id
================================================
71d59ed566ae148b8bf42331a84754ac
================================================
FILE: locales/cy/nogfennau/meini-prawf-cynaliadwyedd-penderfynu/index.md
================================================
# Meini Prawf Cynaliadwyedd Penderfynu
<https://www.infoq.com/articles/sustainable-architectural-design-decisions/>
Er mwyn diffinio cynaliadwyedd penderfyniadau yn fanwl, gwnaethom ddeillio pum maen prawf allweddol.
## Strategol
Wrth wneud penderfyniadau, dylai rhywun sy’n edrych ar ganlyniadau strategol ystyried pethau fel effaith hirdymor y penderfyniadau ’-er enghraifft, gweithrediadau yn y dyfodol ac ymdrech cynnal a chadw.
## Mesuradwy ac yn hylaw
Gallwch fesur a gwerthuso canlyniad penderfyniad dros amser yn unol â meini prawf gwrthrychol, yn ddelfrydol rhai rhifol (fel, er enghraifft, wedi'u lluosogi gan senarios priodoledd ansawdd a gweithdai4). Nid yw dal yr holl benderfyniadau graen mân yn bosibl, felly rhaid i benseiri gyfyngu gronynnedd y penderfyniadau i lefel benodol o fanylion (megis creu dosbarth dylunio). Bydd hyn yn arwain at set fwy cynaliadwy o benderfyniadau a llai o gysylltiadau olrhain. Ar ben hynny, mae cyfyngu ar nifer y dibyniaethau rhwng penderfyniadau yn lleihau effaith cryfhau newidiadau.
## Cyflawnadwy a realistig
Dylai'r rhesymeg dros ffitio'r ateb i'r broblem gael ei ddewis yn bragmatig a'i wneud yn eglur. Er enghraifft, gall penseiri nodi eu bod wedi cymryd gofal i osgoi gor-beiriannu neu danseilio (hynny yw, dylent gymhwyso'r dull “digon da”).
## wedi'i wreiddio mewn gofynion
Dylai gwneud penderfyniadau gael ei seilio ar brofiad pensaernïaeth a chyd-destun pensaernïaeth parth-benodol. Dylai ystyried amgylchedd y cwmni yn ogystal â gofynion a chyfyngiadau prosiect, gan gynnwys sgiliau cyfredol y tîm datblygu, cyllideb hyfforddi a phroses.
## Amserol
Dylai penderfyniadau fod yn seiliedig ar brofiad a gwybodaeth nad ydynt yn debygol o fod wedi dyddio cyn bo hir. Er enghraifft, gall penseiri ddewis patrymau neu dactegau pensaernïol niwtral platfform.
================================================
FILE: locales/cy/nogfennau/proses-cofnodion-penderfynol-pensaernïol-aws/.locale-peer-id
================================================
7d4adf16004ca42546dee49922ae4ccf
================================================
FILE: locales/cy/nogfennau/proses-cofnodion-penderfynol-pensaernïol-aws/index.md
================================================
# Proses Cofnodion Penderfynol Pensaernïol AWS
https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html
Mae cofnod penderfyniad pensaernïol (ADR) yn ddogfen sy'n disgrifio dewis y mae'r tîm yn ei wneud am agwedd sylweddol ar y bensaernïaeth feddalwedd y maent yn bwriadu ei hadeiladu. Mae pob ADR yn disgrifio'r penderfyniad pensaernïol, ei gyd -destun, a'i ganlyniadau. Mae gan ADRs wladwriaethau ac felly'n dilyn cylch bywyd. Am enghraifft o ADR, gweler yr Atodiad.
Mae'r broses ADR yn allbynnu casgliad o gofnodion penderfyniadau pensaernïol. Mae'r casgliad hwn yn creu'r log penderfyniadau. Mae'r log penderfyniadau yn darparu cyd -destun y prosiect yn ogystal â gwybodaeth weithredu a dylunio fanwl. Mae aelodau'r prosiect yn sgimio penawdau pob ADR i gael trosolwg o gyd -destun y prosiect. Maent yn darllen yr ADRs i blymio'n ddwfn i weithrediadau prosiect a dewisiadau dylunio.
Pan fydd y tîm yn derbyn ADR, mae'n dod yn anadferadwy. Os oes angen penderfyniad gwahanol ar fewnwelediadau newydd, mae'r tîm yn cynnig ADR newydd. Pan fydd y tîm yn derbyn yr ADR newydd, mae'n disodli'r ADR blaenorol.
## Cwmpas y broses ADR
Dylai aelodau'r prosiect greu ADR ar gyfer pob penderfyniad pensaernïol arwyddocaol sy'n effeithio ar y prosiect meddalwedd neu'r cynnyrch, gan gynnwys y canlynol (Richards a Ford 2020):
* Strwythur (er enghraifft, patrymau fel microservices)
* Gofynion an swyddogaethol (diogelwch, argaeledd uchel, a goddefgarwch nam)
* Dibyniaethau (cyplu cydrannau)
* Rhyngwynebau (APIs a chontractau cyhoeddedig)
* Technegau adeiladu (llyfrgelloedd, fframweithiau, offer a phrosesau)
* Gofynion swyddogaethol ac an swyddogaethol yw'r mewnbynnau mwyaf cyffredin i'r broses ADR.
## CYNNWYS ADR
Pan fydd y tîm yn nodi'r angen am ADR, mae aelod o'r tîm yn dechrau ysgrifennu'r ADR yn seiliedig ar dempled ledled y prosiect. (Gweler Sefydliad ADR GitHub er enghraifft templedi.) Mae'r templed yn symleiddio creu ADR ac yn sicrhau bod yr ADR yn cyfleu'r holl wybodaeth berthnasol. O leiaf, dylai pob ADR ddiffinio cyd -destun y penderfyniad, y penderfyniad ei hun, a chanlyniadau'r penderfyniad ar gyfer y prosiect a'i gyflawniadau. (Am enghreifftiau o'r adrannau hyn, gweler yr Atodiad.) Un o agweddau mwyaf pwerus strwythur yr ADR yw ei fod yn canolbwyntio ar y rheswm dros y penderfyniad yn hytrach na sut y gwnaeth y tîm ei weithredu. Mae deall pam y gwnaeth y tîm y penderfyniad yn ei gwneud hi'n haws i aelodau eraill y tîm fabwysiadu'r penderfyniad, ac mae'n atal penseiri eraill nad oeddent yn rhan o'r broses benderfynu i ddiystyru'r penderfyniad hwnnw yn y dyfodol.
## Proses fabwysiadu ADR
Gall pob aelod o'r tîm greu ADR, ond dylai'r tîm sefydlu diffiniad o berchnogaeth ar gyfer ADR. Dylai pob awdur sy'n berchennog ADR gynnal a chyfleu'r cynnwys ADR yn weithredol. Er mwyn egluro'r berchnogaeth hon, mae'r canllaw hwn yn cyfeirio at awduron ADR fel perchnogion ADR yn yr adrannau canlynol. Gall aelodau eraill y tîm bob amser gyfrannu at ADR. Os yw cynnwys ADR yn newid cyn i'r tîm dderbyn yr ADR, dylai'r perchennog gymeradwyo'r newidiadau hyn.
Ar ôl i'r tîm nodi penderfyniad pensaernïol a'i berchennog, mae perchennog yr ADR yn darparu'r ADR yn y wladwriaeth ** ** ** ar ddechrau'r broses. Mae ADRs yn y wladwriaeth arfaethedig yn barod i'w hadolygu.
Yna mae perchennog yr ADR yn cychwyn y broses adolygu ar gyfer yr ADR. Nod y broses adolygu ADR yw penderfynu a yw'r tîm yn derbyn yr ADR, yn penderfynu bod angen ei ailweithio, neu'n gwrthod yr ADR. Mae tîm y prosiect, gan gynnwys y perchennog, yn adolygu'r ADR. Dylai'r cyfarfod adolygu ddechrau gyda slot amser pwrpasol i ddarllen yr ADR. Ar gyfartaledd, dylai 10 i 15 munud fod yn ddigon. Yn ystod yr amser hwn, mae pob aelod o'r tîm yn darllen y ddogfen ac yn ychwanegu sylwadau a chwestiynau i dynnu sylw at bynciau aneglur. Ar ôl y cam adolygu, mae perchennog yr ADR yn darllen allan ac yn trafod pob sylw gyda'r tîm.
Os yw'r tîm yn dod o hyd i bwyntiau gweithredu i wella'r ADR, mae cyflwr yr ADR yn aros ** arfaethedig **. Mae perchennog ADR yn llunio'r gweithredoedd, ac, mewn cydweithrediad â'r tîm, yn ychwanegu aseinai at bob gweithred. Gall pob aelod o'r tîm gyfrannu a datrys y pwyntiau gweithredu. Cyfrifoldeb perchennog yr ADR yw aildrefnu'r broses adolygu.
Gall y tîm hefyd benderfynu gwrthod yr ADR. Yn yr achos hwn, mae perchennog yr ADR yn ychwanegu rheswm dros y gwrthod i atal trafodaethau ar yr un pwnc yn y dyfodol. Mae'r perchennog yn newid y wladwriaeth ADR i ** Gwrthod **.
Os yw'r tîm yn cymeradwyo'r ADR, mae'r perchennog yn ychwanegu stamp amser, fersiwn, a rhestr o randdeiliaid. Yna mae'r perchennog yn diweddaru'r wladwriaeth i ** a dderbynnir **.
Mae ADRs a'r log penderfyniadau y maent yn ei greu yn cynrychioli penderfyniadau a wneir gan y tîm ac yn darparu hanes o'r holl benderfyniadau. Mae'r tîm yn defnyddio'r ADRs fel cyfeiriad yn ystod adolygiadau cod a phensaernïol lle bo hynny'n bosibl. Yn ogystal â pherfformio adolygiadau cod, tasgau dylunio, a thasgau gweithredu, dylai aelodau'r tîm ymgynghori ag ADRs ar gyfer penderfyniadau strategol ar gyfer y cynnyrch.
Fel arfer da, dylai pob newid meddalwedd fynd trwy adolygiadau cymheiriaid ac mae angen o leiaf un gymeradwyaeth. Yn ystod yr adolygiad cod, gallai adolygydd cod ddod o hyd i newidiadau sy'n torri un neu fwy o ADRs. Yn yr achos hwn, mae'r adolygydd yn gofyn i awdur y newid cod ddiweddaru'r cod, ac mae'n rhannu dolen i'r ADR. Pan fydd yr awdur yn diweddaru'r cod, caiff ei gymeradwyo gan adolygwyr cymheiriaid a'i uno â'r prif sylfaen cod.
## Proses Adolygu ADR
Dylai'r tîm drin ADRs fel dogfennau na ellir eu symud ar ôl i'r tîm eu derbyn neu eu gwrthod. Mae angen creu ADR newydd, sefydlu proses adolygu ar gyfer yr ADR newydd i newidiadau i ADR sy'n bodoli eisoes, a chymeradwyo'r ADR. Os yw'r tîm yn cymeradwyo'r ADR newydd, dylai'r perchennog newid cyflwr yr hen ADR i ** disodli **.
================================================
FILE: locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs/.locale-peer-id
================================================
8196518140224596af99a46d512feba3
================================================
FILE: locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs/index.md
================================================
# Sut i ddechrau defnyddio ADRs
I ddechrau defnyddio ADRs, siaradwch â'ch cyd -chwaraewyr am yr ardaloedd hyn.
Adnabod Penderfyniadau:
* Pa mor frys a pha mor bwysig yw'r hysbyseb?
* A oes rhaid ei wneud nawr, neu a all aros nes bod mwy yn hysbys?
* Gall profiad personol a chyfunol, yn ogystal â dulliau ac arferion dylunio cydnabyddedig, gynorthwyo gydag adnabod penderfyniadau.
* Yn ddelfrydol, cadw rhestr todo penderfyniad sy'n ategu'r rhestr TODO cynnyrch.
Gwneud penderfyniadau:
* Mae nifer o dechnegau gwneud penderfyniadau yn bodoli, mae rhai cyffredinol a phensaernïaeth meddalwedd yn benodol i rai, er enghraifft, mapio deialog.
* Mae gwneud penderfyniadau grŵp yn bwnc ymchwil gweithredol.
Deddfu a gorfodi penderfyniadau:
* Defnyddir hysbysebion wrth ddylunio meddalwedd; Felly mae'n rhaid eu cyfleu i randdeiliaid y system sy'n cronni, datblygu a gweithredu gan, a derbyn.
* Mae arddulliau codio amlwg yn bensaernïol ac adolygiadau cod sy'n canolbwyntio ar bryderon pensaernïol a phenderfyniadau yn ddau arfer cysylltiedig.
* Rhaid ystyried hysbysebion hefyd (ail-) wrth foderneiddio system feddalwedd yn esblygiad meddalwedd.
Rhannu Penderfyniadau (dewisol):
* Mae llawer o hysbysebion yn digwydd eto ar draws prosiectau.
* Felly, gall profiadau â phenderfyniadau yn y gorffennol, da a drwg, fod yn asedau gwerthfawr y gellir eu hailddefnyddio wrth ddefnyddio strategaeth rheoli gwybodaeth benodol.
Dogfennaeth Penderfyniad:
* Mae llawer o dempledi ac offer ar gyfer dal penderfyniadau yn bodoli.
* Gweler cymunedau ystwyth, e.e. ADRs M. Nygard.
* Gweler Prosesau Peirianneg Meddalwedd a Phensaernïaeth Traddodiadol, e.e. Cynlluniau bwrdd a awgrymwyd gan IBM UMF a chan Tyree ac Akerman o Capitalone.
Am fwy:
* Mabwysiadir y camau uchod o'r cofnod Wikipedia ar [penderfyniad pensaernïol] (https://en.wikipedia.org/wiki/Architectural_Decision)
================================================
FILE: locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gyda-git/.locale-peer-id
================================================
d6fb3c7d91f95003163e694e74058e9d
================================================
FILE: locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gyda-git/index.md
================================================
# Sut i ddechrau defnyddio ADRs gyda git
Os ydych chi'n hoffi defnyddio rheolaeth fersiwn GIT, yna dyma sut rydyn ni'n hoffi dechrau defnyddio ADRs gyda GIT ar gyfer prosiect meddalwedd nodweddiadol gyda'r cod ffynhonnell.
Creu cyfeiriadur ar gyfer ffeiliau ADR:
`` `sh
$ mkdir adr
`` `
Ar gyfer pob ADR, crëwch ffeil testun, fel `database.txt`:
`` `sh
$ vi database.txt
`` `
Ysgrifennwch unrhyw beth rydych chi ei eisiau yn yr ADR. Gweler y templedi yn yr ystorfa hon am syniadau.
Ymrwymwch yr ADR i'ch repo git.
================================================
FILE: locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gydag-offer/.locale-peer-id
================================================
1a5a03dd6f20cea9f78fb4655a9a7f87
================================================
FILE: locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gydag-offer/index.md
================================================
## Sut i ddechrau defnyddio ADRs gydag offer
Gallwch chi ddechrau defnyddio ADRs gydag offer unrhyw ffordd rydych chi ei eisiau.
Er enghraifft:
* Os ydych chi'n hoffi defnyddio Google Drive a Golygu Ar -lein, yna gallwch chi greu Google Doc, neu Google Sheet.
* Os ydych chi'n hoffi defnyddio rheolaeth fersiwn cod ffynhonnell, fel Git, yna gallwch chi greu ffeil ar gyfer pob ADR.
* Os ydych chi'n hoffi defnyddio offer cynllunio prosiect, fel Atlassian Jira, yna gallwch ddefnyddio traciwr cynllunio'r offeryn.
* Os ydych chi'n hoffi defnyddio wicis, fel mediawiki, yna gallwch chi greu wici ADR.
================================================
FILE: locales/cy/templedi/.locale-peer-id
================================================
70f1f9b3530831bc891a6e9b9b0d27de
================================================
FILE: locales/cy/templedi/index.md
================================================
# Templedi cofnodion penderfyniadau
* [Templed cofnod penderfyniad gan Jeff Tyree ac Art Akerman](templed-cofnod-penderfyniad-gan-jeff-tyree-and-art-akerman)
* [Templed cofnod penderfyniad gan Michael Nygard](templed-cofnod-penderfyniad-gan-michael-nygard)
* [Templed cofnod penderfyniad gan EdgeX](templed-cofnod-penderfyniad-gan-edgex)
* [Templed cofnod penderfyniad ar gyfer patrwm Alecsandraidd](templed-cofnod-penderfyniad-ar-gyfer-patrwm-alecsandraidd)
* [Templed cofnod penderfyniad ar gyfer achos busnes](templed-cofnod-penderfyniad-ar-gyfer-achos-busnes)
* [Templed cofnod benderfyniad y Prosiect MADR](templed-cofnod-penderfyniad-y-prosiect-madr)
* [Templed cofnod penderfyniad gan ddefnyddio Planguage](templed-cofnod-penderfyniad-gan-planguage)
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-achos-busnes/.locale-peer-id
================================================
f6d1fb662640a00f4c66c586233dead9
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-achos-busnes/index.md
================================================
# Templed cofnod penderfyniad ar gyfer achos busnes
Mae’r templed ADR hwn yn pwysleisio creu achos busnes ar gyfer penderfyniad, gan gynnwys meini prawf, ymgeiswyr, a chostau.
## Lefel uchaf
* Teitl
* Statws
* Meini prawf gwerthuso
* Ymgeiswyr i'w hystyried
* Ymchwilio a dadansoddi pob ymgeisydd
* A yw/ddim yn bodloni'r meini prawf a pham
* Dadansoddiad cost
* Dadansoddiad SWOT
* Barn ac adborth
*Argymhelliad
## Plymio dwfn lefel isel
**Teitl**:
* Cymal hanfodol amser byr, llai na 50 nod, fel neges ymrwymo git.
**Statws**:
* Un o'r rhai a gynigiwyd, a dderbyniwyd, a wrthodwyd, a anghymeradwywyd, a ddisodlwyd, etc.
**Meini prawf gwerthuso**:
* Crynodeb: eglurwch yn fyr yr hyn yr ydym yn ceisio ei ddarganfod a pham.
* Manylebau
**Ymgeiswyr i'w hystyried**:
* Crynodeb: eglurwch yn gryno sut y gwnaethom ddarganfod ymgeiswyr, a thynnwch sylw at unrhyw allgleifion.
* Rhestrwch yr holl ymgeiswyr a'r opsiynau cysylltiedig; beth ydym yn ei werthuso fel atebion posibl?
* Manylebau
**Ymchwil a dadansoddiad o bob ymgeisydd**:
* Crynodeb: eglurwch yn fyr y dulliau ymchwil, a thynnwch sylw at batrymau, clystyrau, ac allgleifion.
* A yw/ddim yn bodloni'r meini prawf a pham
* Crynodeb
* Manylebau
* Dadansoddiad cost
* Crynodeb
* Enghreifftiau
* Trwyddedu, megis cytundebau contract ac ymrwymiadau cyfreithiol
* Hyfforddiant, fel uwchsgilio a rheoli newid
* Gweithredu, fel cymorth a chynnal a chadw
* Mesuryddion, fel lled band a defnydd CPU
* Dadansoddiad SWOT
* Crynodeb
* Cryfderau
* Gwendidau
* Cyfleoedd
* Bygythiadau
* Barn ac adborth mewnol
* Crynodeb
* Enghreifftiau
* Gan y tîm, yn ddelfrydol wedi'i ysgrifennu gan y person go iawn
* Gan randdeiliaid eraill
* Priodoleddau ansawdd a.k.a. gofynion traws-swyddogaethol
* Barn ac adborth allanol
* Crynodeb
* Pwy sy'n rhoi'r farn?
* Beth ydych chi wedi ystyried ymgeiswyr eraill?
* Beth ydych chi'n ei greu?
* Enghreifftiau
* B2B neu B2C
* wynebu allanol neu gyflogai yn unig
* bwrdd gwaith neu ffôn symudol
* peilot neu gynhyrchiad
* monolith neu ficrowasanaethau
* Sut wnaethoch chi werthuso'r ymgeiswyr?
* Pam wnaethoch chi ddewis yr enillydd?
* Beth sy'n digwydd ers hynny?
* Enghreifftiau
* Sut mae'r enillydd yn perfformio?
* Pa % o draffig defnyddwyr cynhyrchiad y byd go iawn sy'n llifo trwy'r enillydd?
* Pa fathau o integreiddiadau sydd dan sylw, megis gyda phiblinellau cyflenwi parhaus, systemau rheoli cynnwys, dadansoddeg a metrigau, ac ati?
* Gan wybod beth rydych chi'n ei wybod nawr, beth fyddech chi'n cynghori pobl i'w wneud yn wahanol?
* Hanesion
**Argymhelliad**:
* Crynodeb
* Manylebau
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-patrwm-alecsandraidd/.locale-peer-id
================================================
f33e4eb0409f956de201b791749dc9aa
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-patrwm-alecsandraidd/index.md
================================================
# Templed cofnod penderfyniad ar gyfer patrwm Alecsandraidd
## Rhagymadrodd
* Prologue (Crynodeb)
* Trafodaeth (Cyd-destun)
* Ateb (Penderfyniad)
* Canlyniadau (Canlyniadau)
## Manylebau ##
* Prologue (Crynodeb)
* Datganiad i grynhoi:
* Yng nghyd-destun (achos defnydd)<br>
wynebu (pryder)<br>
penderfynon ni ar gyfer (opsiwn)<br>
i gyflawni (ansawdd)<br>
derbyn (anfantais).
* Trafodaeth (Cyd-destun)
* Yn egluro'r grymoedd sydd ar waith (technegol, gwleidyddol, cymdeithasol, prosiect).
* Dyma'r stori sy'n esbonio'r broblem yr ydym am ei datrys.
* Ateb
* Egluro sut y bydd y penderfyniad yn datrys y broblem.
* Canlyniadau
* Yn egluro canlyniadau'r penderfyniad dros y tymor hir.
* A weithiodd, nid gweithio, ei newid, ei uwchraddio, ac ati.
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-edgex/.locale-peer-id
================================================
01939db0c341e9092c344d904065da12
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-edgex/index.md
================================================
# Templed Cofnod Penderfyniad Pensaernïaeth (ADR) <!-- Rhoi teitl ADR --> yn ei le
Mae hwn yn dempled ar gyfer EdgeX Foundry ADR.
Ffynhonnell: https://docs.edgexfoundry.org/2.3/design/adr/template/
### Cyflwynwyr
Rhestrwch y rhai sy'n cyflwyno ADR.
Fformat:
- Enw (Sefydliad)
## Log Newid
Rhestrwch y newidiadau i'r ddogfen, gan gynnwys. cyflwr, dyddiad, a PR URL.
Mae'r wladwriaeth yn un o: arfaeth, cymeradwy, diwygio, anghymeradwy.
Mae'r dyddiad yn llinyn ISO 8601 (BBBB-MM-DD).
PR yw’r cais tynnu a gyflwynodd y newid, gan gynnwys gwybodaeth fel y diffynnydd, cyfranwyr, ac adolygwyr.
Fformat:
- \[ Statws ADR e.e. cymeradwyo, diwygio, ac ati\]\(URL cais tynnu\) BBBB-MM-DD
## Achos(ion) Defnydd Cyfeiriedig
Rhestrwch yr holl ddogfennau achos defnydd / gofynion perthnasol.
Mae ADR yn gofyn am o leiaf un achos defnydd cymeradwy perthnasol.
Fformat:
- \[Defnyddiwch Enw'r Achos\]\(URL\)
Ychwanegu esboniadau os nad yw'r ADR yn mynd i'r afael â holl ofynion achos defnydd.
## Cyd-destun
Disgrifiwch:
- sut mae'r dyluniad yn arwyddocaol yn bensaernïol - gwarantu ADR (yn erbyn mater syml a chysylltiadau cyhoeddus i ddatrys problem)
- y dull dylunio lefel uchel (manylion a ddisgrifir yn y dyluniad arfaethedig isod)
## Dyluniad Arfaethedig
Manylion y dyluniad (heb ddechrau gweithredu lle bo modd).
Amlinelliad:
- gwasanaethau/modiwlau i gael eu heffeithio (newid)
- gwasanaethau/modiwlau newydd i'w hychwanegu
- effaith model ac DTO (newidiadau/ychwanegiadau/dileu)
- Effaith API (newidiadau / ychwanegiadau / dileu)
- effaith cyfluniad cyffredinol (sefydlu adrannau newydd, newidiadau / ychwanegiadau / dileu)
- devops effaith
## Ystyriaethau
Dogfennu dewisiadau eraill, pryderon, materion ategol neu gysylltiedig, cwestiynau a gododd wrth drafod yr ADR.
Nodwch os/sut y cawsant eu datrys neu eu moli.
## Penderfyniad
Dogfennu unrhyw fanylion gweithredu pwysig y cytunwyd arnynt, rhybuddion, ystyriaethau yn y dyfodol, materion dylunio sy'n weddill neu'n cael eu gohirio.
Dogfennu unrhyw ran o'r gofynion nad ydynt yn cael eu bodloni gan y dyluniad arfaethedig.
## ADRs Cysylltiedig Eraill
Rhestrwch unrhyw ADRs perthnasol - megis penderfyniad dylunio ar gyfer is-gydran o nodwedd, dyluniad sydd wedi'i anghymeradwyo o ganlyniad i'r dyluniad hwn, ac ati.
Fformat:
- \[ADR Title\]\(URL\) - Perthnasedd
## Cyfeiriadau
Rhestrwch gyfeiriadau ychwanegol.
Fformat:
- \[Teitl\]\(URL\)
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-jeff-tyree-and-art-akerman/.locale-peer-id
================================================
f4ca0a94124a91279e1929ea23ab864d
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-jeff-tyree-and-art-akerman/index.md
================================================
# Templed cofnod penderfyniad gan Jeff Tyree ac Art Akerman
Dyma'r templed disgrifiad penderfyniad pensaernïaeth a gyhoeddwyd yn ["Architecture Decisions: Demystifying Architecture" gan Jeff Tyree ac Art Akerman, Capital One Financial]( https://www.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions- tyree-05.pdf).
* **Mater**: Disgrifiwch y mater dylunio pensaernïol rydych chi'n mynd i'r afael ag ef, heb adael unrhyw gwestiynau ynghylch pam rydych chi'n mynd i'r afael â'r mater hwn nawr. Gan ddilyn ymagwedd finimalaidd, rhowch sylw i'r materion y mae angen mynd i'r afael â hwy ar wahanol adegau yn ystod y cylch bywyd a'u dogfennu.
* **Penderfyniad**: Nodwch yn glir gyfeiriad y bensaernïaeth - hynny yw, y swydd rydych chi wedi'i dewis.
* **Statws**: Statws y penderfyniad, megis yr arfaeth, y penderfynwyd arno, neu a gymeradwywyd.
* **Grŵp**: Gallwch ddefnyddio grwpio syml - fel integreiddio, cyflwyniad, data, ac yn y blaen - i helpu i drefnu'r set o benderfyniadau. Gallech hefyd ddefnyddio ontoleg pensaernïaeth fwy soffistigedig, fel John Kyaruzi a Jan van Katwijk's, sy'n cynnwys categorïau mwy haniaethol fel digwyddiad, calendr, a lleoliad. Er enghraifft, gan ddefnyddio'r ontoleg hon, byddech chi'n grwpio penderfyniadau sy'n delio â digwyddiadau lle mae angen gwybodaeth ar y system dan ddigwyddiad.
* ** Tybiaethau**: Disgrifiwch yn glir y tybiaethau sylfaenol yn yr amgylchedd lle rydych chi'n gwneud y penderfyniad - cost, amserlen, technoleg, ac ati. Sylwch y gallai cyfyngiadau amgylcheddol (fel safonau technoleg derbyniol, pensaernïaeth menter, patrymau a ddefnyddir yn gyffredin, ac yn y blaen) gyfyngu ar y dewisiadau eraill rydych chi'n eu hystyried.
* **Cyfyngiadau**: Nodwch unrhyw gyfyngiadau ychwanegol i'r amgylchedd y gallai'r dewis arall a ddewiswyd (y penderfyniad) ei achosi.
* **Swyddi**: Rhestrwch y swyddi (opsiynau hyfyw neu ddewisiadau eraill) y gwnaethoch eu hystyried. Mae'r rhain yn aml yn gofyn am esboniadau hir, weithiau hyd yn oed modelau a diagramau. Nid yw hon yn rhestr gyflawn. Fodd bynnag, nid ydych chi eisiau clywed y cwestiwn "Wnest ti feddwl am...?" yn ystod adolygiad terfynol; mae hyn yn arwain at golli hygrededd a chwestiynu penderfyniadau pensaernïol eraill. Mae’r adran hon hefyd yn helpu i sicrhau eich bod wedi clywed barn pobl eraill; mae datgan barnau eraill yn benodol yn helpu i gofrestru eu heiriolwyr yn eich penderfyniad.
* **Dadl**: Amlinellwch pam y dewisoch chi swydd, gan gynnwys eitemau fel cost gweithredu, cyfanswm cost perchnogaeth, amser i’r farchnad, ac argaeledd yr adnoddau datblygu gofynnol. Mae'n debyg bod hyn yr un mor bwysig â'r penderfyniad ei hun.
* **Goblygiadau**: Daw llawer o oblygiadau i benderfyniad, fel y mae metamodel REMAP yn ei ddynodi. Er enghraifft, gallai penderfyniad gyflwyno angen i wneud penderfyniadau eraill, creu gofynion newydd, neu addasu gofynion presennol; gosod cyfyngiadau ychwanegol ar yr amgylchedd; gofyn am ail-negodi cwmpas neu amserlen gyda chwsmeriaid; neu angen hyfforddiant staff ychwanegol. Yn amlwg, gall deall a datgan goblygiadau eich penderfyniad fod yn effeithiol iawn wrth ennill cefnogaeth a chreu map ffordd ar gyfer gweithredu pensaernïaeth.
* **Penderfyniadau cysylltiedig**: Mae’n amlwg bod llawer o benderfyniadau yn gysylltiedig; gallwch eu rhestru yma. Fodd bynnag, yn ymarferol, rydym wedi canfod bod matrics olrhain, coed penderfynu, neu fetamodelau yn fwy defnyddiol. Mae metafodelau yn ddefnyddiol ar gyfer dangos perthnasoedd cymhleth ar ffurf diagramau (fel modelau Rose).
* **Gofynion cysylltiedig**: Dylai penderfyniadau gael eu gyrru gan fusnes. I ddangos atebolrwydd, mapiwch eich penderfyniadau yn benodol i'r amcanion neu'r gofynion. Gallwch gyfrif y gofynion cysylltiedig hyn yma, ond rydym wedi ei chael yn fwy cyfleus cyfeirio at fatrics olrhain. Gallwch asesu cyfraniad pob penderfyniad pensaernïaeth at fodloni pob gofyniad, ac yna asesu pa mor dda y bodlonir y gofyniad ar draws pob penderfyniad. Os nad yw penderfyniad yn cyfrannu at fodloni gofyniad, peidiwch â gwneud y penderfyniad hwnnw.
* **Arteffactau cysylltiedig**: Rhestrwch y dogfennau pensaernïaeth, dyluniad neu gwmpas cysylltiedig y mae'r penderfyniad hwn yn effeithio arnynt.
* **Egwyddorion cysylltiedig**: Os oes gan y fenter set o egwyddorion y cytunwyd arnynt, gwnewch yn siŵr bod y penderfyniad yn gyson ag un neu fwy ohonynt. Mae hyn yn helpu i sicrhau aliniad ar hyd parthau neu systemau.
* **Nodiadau**: Gan fod y broses benderfynu yn gallu cymryd wythnosau, rydym wedi ei chael yn ddefnyddiol i gasglu nodiadau a materion y mae’r tîm yn eu trafod yn ystod y broses gymdeithasoli.
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-michael-nygard/.locale-peer-id
================================================
b1e90e6556c1c8f1e2eb3ac22c8c5077
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-michael-nygard/index.md
================================================
# Templed cofnod penderfyniad gan Michael Nygard
Dyma'r templed yn [Dogfennu penderfyniadau pensaernïaeth - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
Gallwch ddefnyddio [adr-tools](https://github.com/npryce/adr-tools) ar gyfer rheoli'r ffeiliau ADR.
Ym mhob ffeil ADR, ysgrifennwch yr adrannau hyn:
# Teitl
## Statws
Beth yw'r statws, megis y rhai a gynigir, a dderbyniwyd, a wrthodwyd, a anghymeradwywyd, a ddisodlwyd, ac ati?
## Cyd-destun
Beth yw'r mater yr ydym yn ei weld sy'n ysgogi'r penderfyniad neu'r newid hwn?
## Penderfyniad
Beth yw'r newid rydym yn ei gynnig a/neu'n ei wneud?
## Canlyniadau
Beth sy'n dod yn haws neu'n anos i'w wneud oherwydd y newid hwn?
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-planguage/.locale-peer-id
================================================
bb37e19df57d398b0704d6bd30ee6e6d
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-gan-planguage/index.md
================================================
# Templed cofnod penderfyniad gan ddefnyddio Planguage
Gweler https://www.iaria.org/conferences2012/filesICCGI12/Tutorial%20Specifying%20Effective%20Non-func.pdf
## Beth yw Planguage?
Mae Planguage yn iaith gynllunio sy'n defnyddio'r geiriau allweddol hyn:
* Tag: Dynodwr unigryw, parhaus
* Gist: Crynodeb byr o'r gofyniad neu'r maes dan sylw
* Gofyniad: Y testun sy'n manylu ar y gofyniad ei hun
* Rhesymeg: Y rhesymu sy'n cyfiawnhau'r gofyniad
* Blaenoriaeth: Datganiad o flaenoriaeth a hawliad ar adnoddau
* Rhanddeiliaid: Partïon yr effeithir arnynt yn sylweddol gan y gofyniad
* Statws: Statws y gofyniad (drafft, wedi'i adolygu, wedi ymrwymo, ac ati)
* Perchennog: Y person sy'n gyfrifol am weithredu'r gofyniad
* Awdur: Y person a ysgrifennodd y gofyniad
* Adolygu: Rhif fersiwn ar gyfer y datganiad
* Dyddiad: Dyddiad y diwygiad diweddaraf
* Tybiaethau: Unrhyw beth a allai achosi problemau os yw'n anwir nawr neu'n hwyrach
* Risgiau: Unrhyw beth a allai achosi camweithio, oedi, neu effeithiau negyddol eraill
* Diffiniedig: Diffiniad o derm (gwell defnyddio geirfa)
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-y-prosiect-madr/.locale-peer-id
================================================
0a9f88e5cda952db0a82d071f585d090
================================================
FILE: locales/cy/templedi/templed-cofnod-penderfyniad-y-prosiect-madr/index.md
================================================
# [teitl byr y broblem a'r datrysiad a ddatryswyd]
* Statws: [ arfaethedig | gwrthodwyd | derbyn | anghymeradwy | … | wedi'i ddisodli gan [ADR-0005](0005-example.md)] <!-- dewisol -->
* Penderfynwyr: [rhestrwch bawb sy'n rhan o'r penderfyniad] <!-- dewisol -->
*Dyddiad: [YYYY-MM-DD pan gafodd y penderfyniad ei ddiweddaru ddiwethaf] <!-- optional -->
Stori Dechnegol: [disgrifiad | URL tocyn/rhifyn] <!-- dewisol -->
## Datganiad Cyd-destun a Phroblem
[Disgrifiwch y cyd-destun a gosodiad y broblem, e.e., ar ffurf rydd gan ddefnyddio dwy neu dair brawddeg. Efallai y byddwch am fynegi’r broblem ar ffurf cwestiwn.]
## Gyrwyr Penderfyniad <!-- dewisol -->
* [gyrrwr 1, e.e., llu, yn wynebu pryder, …]
* [gyrrwr 2, e.e., llu, yn wynebu pryder, …]
* … <!-- gall nifer y gyrwyr amrywio -->
## Opsiynau a Ystyrir
* [opsiwn 1]
* [opsiwn 2]
* [opsiwn 3]
* … <!-- gall nifer yr opsiynau amrywio -->
## Canlyniad Penderfyniad
Dewis a ddewiswyd: "[opsiwn 1]", oherwydd [cyfiawnhad. e.e., opsiwn yn unig, sy'n bodloni k.o. gyrrwr penderfyniad maen prawf | sy'n datrys grym grym | … | yn dod allan orau (gweler isod)].
### Canlyniadau Cadarnhaol <!-- dewisol -->
* [e.e., gwella boddhad priodoledd ansawdd, penderfyniadau dilynol sydd eu hangen, …]
*…
### Canlyniadau Negyddol <!-- dewisol -->
* [e.e., cyfaddawdu priodoledd ansawdd, penderfyniadau dilynol sydd eu hangen, …]
*…
## Manteision ac Anfanteision yr Opsiynau <!-- dewisol -->
### [opsiwn 1]
[enghraifft | disgrifiad | pwyntydd at ragor o wybodaeth | …] <!-- dewisol -->
* Da, oherwydd [dadl a]
* Da, achos [dadl b]
* Drwg, oherwydd [dadl c]
* … <!-- gall nifer y manteision a'r anfanteision amrywio -->
### [opsiwn 2]
[enghraifft | disgrifiad | pwyntydd at ragor o wybodaeth | …] <!-- dewisol -->
* Da, oherwydd [dadl a]
* Da, achos [dadl b]
* Drwg, oherwydd [dadl c]
* … <!-- gall nifer y manteision a'r anfanteision amrywio -->
### [opsiwn 3]
[enghraifft | disgrifiad | pwyntydd at ragor o wybodaeth | …] <!-- dewisol -->
* Da, oherwydd [dadl a]
* Da, achos [dadl b]
* Drwg, oherwydd [dadl c]
* … <!-- gall nifer y manteision a'r anfanteision amrywio -->
## Dolenni <!-- dewisol -->
* [Math o ddolen] [Cyswllt i ADR] <!-- enghraifft: Wedi'i fireinio gan [ADR-0005](0005-example.md) -->
* … <!-- gall nifer y dolenni amrywio -->
================================================
FILE: locales/en/.locale-peer-id
================================================
0b59cb46e5817b414866ebe33f4d7bcf
================================================
FILE: locales/en/documents/.locale-peer-id
================================================
abc7c72d426bc75e40b25a44ae37ce73
================================================
FILE: locales/en/documents/aws-adr-process/.locale-peer-id
================================================
7d4adf16004ca42546dee49922ae4ccf
================================================
FILE: locales/en/documents/aws-adr-process/index.md
================================================
# AWS Architectural Decision Records Process
https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html
An architectural decision record (ADR) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re planning to build. Each ADR describes the architectural decision, its context, and its consequences. ADRs have states and therefore follow a lifecycle. For an example of an ADR, see the appendix.
The ADR process outputs a collection of architectural decision records. This collection creates the decision log. The decision log provides the project context as well as detailed implementation and design information. Project members skim the headlines of each ADR to get an overview of the project context. They read the ADRs to dive deep into project implementations and design choices.
When the team accepts an ADR, it becomes immutable. If new insights require a different decision, the team proposes a new ADR. When the team accepts the new ADR, it supersedes the previous ADR.
## Scope of the ADR process
Project members should create an ADR for every architecturally significant decision that affects the software project or product, including the following (Richards and Ford 2020):
* Structure (for example, patterns such as microservices)
* Non-functional requirements (security, high availability, and fault tolerance)
* Dependencies (coupling of components)
* Interfaces (APIs and published contracts)
* Construction techniques (libraries, frameworks, tools, and processes)
* Functional and non-functional requirements are the most common inputs to the ADR process.
## ADR contents
When the team identifies a need for an ADR, a team member starts to write the ADR based on a projectwide template. (See the ADR GitHub organization for example templates.) The template simplifies ADR creation and ensures that the ADR captures all the relevant information. At a minimum, each ADR should define the context of the decision, the decision itself, and the consequences of the decision for the project and its deliverables. (For examples of these sections, see the appendix.) One of the most powerful aspects of the ADR structure is that it focuses on the reason for the decision rather than how the team implemented it. Understanding why the team made the decision makes it easier for other team members to adopt the decision, and prevents other architects who weren’t involved in the decision-making process to overrule that decision in the future.
## ADR adoption process
Every team member can create an ADR, but the team should establish a definition of ownership for an ADR. Each author who is the owner of an ADR should actively maintain and communicate the ADR content. To clarify this ownership, this guide refers to ADR authors as ADR owners in the following sections. Other team members can always contribute to an ADR. If the content of an ADR changes before the team accepts the ADR, the owner should approve these changes.
After the team identifies an architectural decision and its owner, the ADR owner provides the ADR in the **Proposed** state at the beginning of the process. ADRs in the Proposed state are ready for review.
The ADR owner then initiates the review process for the ADR. The goal of the ADR review process is to decide whether the team accepts the ADR, determines that it needs rework, or rejects the ADR. The project team, including the owner, reviews the ADR. The review meeting should start with a dedicated time slot to read the ADR. On average, 10 to 15 minutes should be enough. During this time, each team member reads the document and adds comments and questions to flag unclear topics. After the review phase, the ADR owner reads out and discusses each comment with the team.
If the team finds action points to improve the ADR, the state of the ADR stays **Proposed**. The ADR owner formulates the actions, and, in collaboration with the team, adds an assignee to each action. Each team member can contribute and resolve the action points. It is the responsibility of the ADR owner to reschedule the review process.
The team can also decide to reject the ADR. In this case, the ADR owner adds a reason for the rejection to prevent future discussions on the same topic. The owner changes the ADR state to **Rejected**.
If the team approves the ADR, the owner adds a timestamp, version, and list of stakeholders. The owner then updates the state to **Accepted**.
ADRs and the decision log they create represent decisions made by the team and provide a history of all decisions. The team uses the ADRs as a reference during code and architectural reviews where possible. In addition to performing code reviews, design tasks, and implementation tasks, team members should consult ADRs for strategic decisions for the product.
As a good practice, each software change should go through peer reviews and require at least one approval. During the code review, a code reviewer might find changes that violate one or more ADRs. In this case, the reviewer asks the author of the code change to update the code, and shares a link to the ADR. When the author updates the code, it is approved by peer reviewers and merged into the main code base.
## ADR review process
The team should treat ADRs as immutable documents after the team accepts or rejects them. Changes to an existing ADR requires creating a new ADR, establishing a review process for the new ADR, and approving the ADR. If the team approves the new ADR, the owner should change the state of the old ADR to **Superseded**.
================================================
FILE: locales/en/documents/decision-sustainability-criteria/.locale-peer-id
================================================
71d59ed566ae148b8bf42331a84754ac
================================================
FILE: locales/en/documents/decision-sustainability-criteria/index.md
================================================
# Decision Sustainability Criteria
<https://www.infoq.com/articles/sustainable-architectural-design-decisions/>
To define decision sustainability in detail, we derived five key criteria.
## Strategic
During decision making, someone looking at strategic consequences should consider things such as the decisions’ long-term impact—for example, future operations and maintenance effort.
## Measurable and Manageable
You can measure and evaluate a decision’s outcome over time according to objective criteria, ideally numeric ones (as, for instance, propagated by quality attribute scenarios and workshops4). Capturing all fine-grained decisions isn’t possible, so architects must limit the decisions’ granularity to a certain level of detail (such as creating a design class). This will lead to a more sustainable set of decisions and fewer traceability links. Moreover, limiting the number of dependencies between decisions reduces changes’ ripple effect.
## Achievable and Realistic
The rationale for fitting the solution to the problem should be chosen pragmatically and made explicit. For example, architects can indicate that they have taken care to avoid over- or underengineering (that is, they should apply the “good enough” approach).
## Rooted in Requirements
Decision making should be grounded in domain-specific architecting experience and context. It should take into account the company environment as well as project requirements and constraints, including the development team’s current skills, training budget, and process.
## Timeless
Decisions should be based on experience and knowledge that won’t likely be soon outdated. For example, architects can choose platform-neutral architectural patterns or tactics.
================================================
FILE: locales/en/documents/file-name-conventions-for-adrs/.locale-peer-id
================================================
89116b5647aa1e53186f3c44b5a284a0
================================================
FILE: locales/en/documents/file-name-conventions-for-adrs/index.md
================================================
# File name conventions
If you choose to create your ADRs using typical text files, then you may want to come up with your own ADR file name convention.
We prefer to use a file name convention that has a specific format.
Examples:
* choose-database.md
* format-timestamps.md
* manage-passwords.md
* handle-exceptions.md
Our file name convention:
* The name has a present tense imperative verb phrase. This helps readability and matches our commit message format.
* The name uses lowercase and dashes (same as this repo). This is a balance of readability and system usability.
* The extension is markdown. This can be useful for easy formatting.
================================================
FILE: locales/en/documents/fitness-functions-for-decisions-as-code/.locale-peer-id
================================================
23615a056e17c4097ee648d8c7352733
================================================
FILE: locales/en/documents/fitness-functions-for-decisions-as-code/index.md
================================================
# Fitness functions for decisions as code
Fitness functions are objective automated checks, written with programming code, that verify decisions are being maintained.
- Fitness functions make decisions testable and assurable.
- Fitness functions for decisions can greatly help quality assurance, regulatory processes, and governance goals.
## How fitness functions connect to decisions
A decision record documents the decision, while a fitness function assures the decision.
- Example decision: We use event sourcing for audit requirements.
- Example fitness function: We use the continuous integration server to test that all state changes must produce events.
## Why fitness functions help decisions
Objective measurements: Fitness functions pass or fail, so work is visible and clear.
Continuous use: Fitness functions are your living rules, run on every commit and build.
Confidence to refactor: Fitness functions automatically catch decision rule errors.
Scalable governance: Fitness functions assure standards without creating bottlenecks.
## Can fitness functions use AI?
Fitness functions can leverage AI LLMs for decisions by asking questions for your work,
such as your plans, code, schemas, APIs, and more:
```txt
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.
```
## Architecture unit testing
[ArchUnit](https://www.archunit.org/): check architecture rules of Java code by using any plain Java unit test framework.
[ArchUnitTS](https://github.com/LukasNiessen/ArchUnitTS): check architecture rules of TypeScript code and JavaScript code by using Jest, Vitest, Jasmine, etc.
================================================
FILE: locales/en/documents/guidelines-to-achieve-sustainable-decisions/.locale-peer-id
================================================
934d1c42a693fe004cd8bf8f5ecb97e6
================================================
FILE: locales/en/documents/guidelines-to-achieve-sustainable-decisions/index.md
================================================
# Guidelines to Achieve Sustainable Decisions
<https://www.infoq.com/articles/sustainable-architectural-design-decisions/>
We learned the following lessons in our work that can serve as guidelines and assessment for achieving sustainable decisions:
1. Use a lean/minimalistic approach for the initial decision documentation.
2. Prioritize and capture all important decisions that are relevant enough for documenting and understanding the target architecture.
3. Detail the particularly important decisions with full-blown templates only after the initial work has been done (that is, when the decision makers are content with the architectural decisions made and confident that these decisions don’t have to be revised any time soon).
4. Use the lean/minimalistic versions from step 1 as a short version of documented decisions with the right granularity level to provide an overview of the detailed decisions, as well as for trivial or obvious decisions.
5. Wherever possible, use existing architectural knowledge, either from guidance models or from other sources. Review and extend such knowledge and fit it to the context of the specific decision.
6. Ensure that traceability links are established between decisions and both requirements and architectural designs/code.
7. Provide automated consistency checking to make sure the traceability links are in sync after a change. Limit the number of dependencies between decisions and other software artifacts.
8. Apply the guidelines for the justifications consequently and forcefully—they’re the most important part of the decision documentation because they give the rationale.
================================================
FILE: locales/en/documents/how-to-start-using-adrs/.locale-peer-id
================================================
8196518140224596af99a46d512feba3
================================================
FILE: locales/en/documents/how-to-start-using-adrs/index.md
================================================
# How to start using ADRs
To start using ADRs, talk with your teammates about these areas.
Decision identification:
* How urgent and how important is the AD?
* Does it have to be made now, or can it wait until more is known?
* Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification.
* Ideally maintain a decision todo list that complements the product todo list.
Decision making:
* A number of decision making techniques exists, both general ones and software architecture specific ones, for instance, dialogue mapping.
* Group decision making is an active research topic.
Decision enactment and enforcement:
* ADs are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it.
* Architecturally evident coding styles and code reviews that focus on architectural concerns and decisions are two related practices.
* ADs also have to be (re-)considered when modernizing a software system in software evolution.
Decision sharing (optional):
* Many ADs recur across projects.
* Hence, experiences with past decisions, both good and bad, can be valuable reusable assets when employing an explicit knowledge management strategy.
Decision documentation:
* Many templates and tools for decision capturing exist.
* See agile communities, e.g. M. Nygard's ADRs.
* See traditional software engineering and architecture design processes, e.g. table layouts suggested by IBM UMF and by Tyree and Akerman from CapitalOne.
For more:
* The steps above are adopted from the Wikipedia entry on [Architectural Decision](https://en.wikipedia.org/wiki/Architectural_decision)
================================================
FILE: locales/en/documents/how-to-start-using-adrs-with-git/.locale-peer-id
================================================
d6fb3c7d91f95003163e694e74058e9d
================================================
FILE: locales/en/documents/how-to-start-using-adrs-with-git/index.md
================================================
# How to start using ADRs with git
If you like using git version control, then here is how we like to start using ADRs with git for a typical software project with source code.
Create a directory for ADR files:
```sh
$ mkdir adr
```
For each ADR, create a text file, such as `database.txt`:
```sh
$ vi database.txt
```
Write anything you want in the ADR. See the templates in this repository for ideas.
Commit the ADR to your git repo.
================================================
FILE: locales/en/documents/how-to-start-using-adrs-with-tools/.locale-peer-id
================================================
1a5a03dd6f20cea9f78fb4655a9a7f87
================================================
FILE: locales/en/documents/how-to-start-using-adrs-with-tools/index.md
================================================
## How to start using ADRs with tools
You can start using ADRs with tools any way you want.
For example:
* If you like using Google Drive and online editing, then you can create a Google Doc, or Google Sheet.
* If you like use source code version control, such as git, then you can create a file for each ADR.
* If you like using project planning tools, such as Atlassian Jira, then you can use the tool's planning tracker.
* If you like using wikis, such as MediaWiki, then you can create an ADR wiki.
================================================
FILE: locales/en/documents/suggestions-for-writing-good-adrs/.locale-peer-id
================================================
dc1a294e76821d6d3b086a2b17988427
================================================
FILE: locales/en/documents/suggestions-for-writing-good-adrs/index.md
================================================
## Suggestions for writing good ADRs
Characteristics of a good ADR:
* Rationale: Explain the reasons for doing the particular AD. This can include the context (see below), pros and cons of various potential choices, feature comparisons, cost/benefit discussions, and more.
* Specific: Each ADR should be about one AD, not multiple ADs.
* Timestamps: Identify when each item in the ADR is written. This is especially important for aspects that may change over time, such as costs, schedules, scaling, and the like.
* Immutable: Don't alter existing information in an ADR. Instead, amend the ADR by adding new information, or supersede the ADR by creating a new ADR.
Characteristics of a good "Context" section in an ADR:
* Explain your organization's situation and business priorities.
* Include rationale and considerations based on social and skills makeups of your teams.
* Include pros and cons that are relevant, and describe them in terms that align with your needs and goals.
Characteristics of good "Consequences" section in an ADR:
* Explain what follows from making the decision. This can include the effects, outcomes, outputs, follow ups, and more.
* Include information about any subsequent ADRs. It's relatively common for one ADR to trigger the need for more ADRs, such as when one ADR makes a big overarching choice, which in turn creates needs for more smaller decisions.
* Include any after-action review processes. It's typical for teams to review each ADR one month later, to compare the ADR information with what's happened in actual practice, in order to learn and grow.
A new ADR may take the place of a previous ADR:
* When an AD is made that replaces or invalidates a previous ADR, then a new ADR should be created
================================================
FILE: locales/en/documents/teamwork-advice-for-adrs/.locale-peer-id
================================================
875a7715e592ceb45eac5e155ee16318
================================================
FILE: locales/en/documents/teamwork-advice-for-adrs/index.md
================================================
# Teamwork advice for ADRs
If you're considering using decision records with your team, then here's some advice that we've learned by working with many teams.
You have an opportunity to lead your teammates, by talking together about the "why", rather than mandating the "what". For example, decision records are a way for teams to think smarter and communicate better; decision records are not valuable if they're just an after-the-fact forced paperwork requirement.
Some teams much prefer the name "decisions" over the abbreviation "ADRs". When some teams use the directory name "decisions", then it's as if a light bulb turns on, and the team starts putting more information into the directory, such as vendor decisions, planning decisions, scheduling decisions, etc. All of these kinds of information can use the same template. We hypothesize that people learn faster with words ("decisions") over abbreviations ("ADRs"), and people are more motivated to write work-in-progress docs when the word "record" is removed, and also some developers and some managers dislike the word "architecture".
In theory, immutability is ideal. In practice, mutability has worked better for our teams. We insert the new info the existing ADR, with a date stamp, and a note that the info arrived after the decision. This kind of approach leads to a "living document" that we all can update. Typical updates are when we get information thanks to new teammates, or new offerings, or real-world results of our usages, or after-the-fact third-party changes such as vendor capabilities, pricing plans, license agreements, etc.
================================================
FILE: locales/en/documents/teamwork-questions-for-adrs/.locale-peer-id
================================================
60057747e4547af35fd888021e41f332
================================================
FILE: locales/en/documents/teamwork-questions-for-adrs/index.md
================================================
### Who can create an ADR?
Consider areas such as specific people, or specific roles, or specific teams, or specific departments; also consider if there are people, or roles, or teams, or department that can commission an ADR, meaning they request one that someone else will author.
Example answer: Any person in our organization who has read the architecture decision record README page can propose an ADR, meaning the person can start writing it, and share it with the team.
### What justifies raising an ADR?
Consider areas such as your organization's team ways of working, your software system structure, cross-team coordination, long-term maintainability, external interfaces, who you want to benefit, and the like.
Example answer: We want to create an ADR when we want future developers to understand the “why” of what we're doing.
### What justifies not raising an ADR?
Consider areas such as decisions that are not about architecture, or are tiny such as minimal-risk or self-contained or single-developer, or are already fully covered elsewhere such as by standards or policies or documentation, or are temporary such as workarounds or proofs of concepts or orexperiments.
Example answer: We want to skip an ADR when a decision is limited in scope and time and risk and cost, or is already covered elsewhere.
### What is the lifecycle of an ADR?
Consider areas such as the creation process, research process, decisioning process, implementation process, and sunsetting process. Consider how to track the ADR lifecycle over time, such as how to move the ADR from one state to the next state, and also how to communicate this to stakeholders.
Example answer: We want an ADR to have five lifecycle stages: Initiating → Researching → Evaluating → Implementing → Maintaining → Sunsetting.
### What are criteria for lifecycle steps of an ADR?
Consider areas such as acceptance criteria for an ADR, meaning how do you know it's good enough to progress from one lifecycle step to the next? Is the problem clearly articulated? Have the alternatives been considered? Are trade-offs well-enough understood and documented?
Is all relevant context in place? Are all relevant stakeholders involved? Has all feedback been incorporated?
Example answer: We want an ADR to be voted on by stakeholders when the active team has 1) completed their research, 2) completed their evaluation, 3) published the ADR proposal to the stakeholders with a request for comments and a timebox of one week, 4) all stakeholder comments have been incorporated and addressed.
### What roles and responsibilities interact with an ADR?
Consider roles such as proposer, researcher, evaluator, reviewer, approver, maintainer, and the like. Consider responsibilities such as communication with stakeholders, ensuring expectations are met, sharing on the website or intranet, and reviewing the work periodically and especially when relevant changes happen.
Example answer: We want each ADR to always have a primary contact person, secondary contact person, and accountable team; these are responsible for communications, publications, maintenance, periodic review at least once per year, and eventual sunsetting as needed.
### How does governance interact with an ADR?
Consider areas such as your organization's ways of working, any special compliance needs such as for legal aspects or human resource aspects, how you want to handle consensus versus conflict versus escalation. Are there areas or people or teams that can have more influence than others regarding an ADR, such as being able to approve it, or vote on it, or veto it?
Example answer: The governance of an ADR is in this priority order: the CEO, the CTO, the CLO, the team that implements an ADR, the experts on the team that are most-knowledgeable about the ADD. No one else has governance unless described in the ADR.
### What principles interact with an ADR?
Consider areas such as your organization's ways of working that include moving quickly versus moving slowly, for decision consensus versus decision conflict, and for risk preferences versus safety preferences, public discussion versus private discussion, and the like.
Example answer: We use the leadership principles of bias for action, disagree-and-commit, 70% estimates are good enough for easily-reversable easily-isolatable decisions, and public ways of working with the exception of confidential information as described in our organization's confidentiality agreement.
================================================
FILE: locales/en/documents/what-is-an-architecture-decision-record/.locale-peer-id
================================================
020ff535ed1a3347a265209291e756b6
================================================
FILE: locales/en/documents/what-is-an-architecture-decision-record/index.md
================================================
## What is an architecture decision record?
An **architecture decision record** (ADR) is a document that captures an important architectural decision made along with its context and consequences.
An **architecture decision** (AD) is a software design choice that addresses a significant requirement.
An **architecture decision log** (ADL) is the collection of all ADRs created and maintained for a particular project (or organization).
An **architecturally-significant requirement** (ASR) is a requirement that has a measurable effect on a software system’s architecture.
All these are within the topic of **architecture knowledge management** (AKM).
The goal of this document is to provide a fast overview of ADRs, how to create them, and where to look for more information.
Abbreviations:
* **AD**: architecture decision
* **ADL**: architecture decision log
* **ADR**: architecture decision record
* **AKM**: architecture knowledge management
* **ASR**: architecturally-significant requirement
================================================
FILE: locales/en/examples/.locale-peer-id
================================================
================================================
FILE: locales/en/examples/4-day-work-week/.locale-peer-id
================================================
fb15d0e84550135e2e7a280693ba5848
================================================
FILE: locales/en/examples/4-day-work-week/index.md
================================================
# Decision record for 4-day work-week
Title: Implementation of 4-Day Work-week
## Context and Problem Statement
Our organization has been considering a switch to a 4-day workweek. The current work schedule of 5 days per week, 8 hours per day, has resulted in low productivity, employee burnout, and high turnover rates. The proposed change aims to increase employee satisfaction, engagement, and retention, and ultimately improve organizational performance.
## Decision
We have decided to implement a 4-day workweek starting from the next quarter for all employees across the organization.
## Rationale
The decision was based on the following factors:
1. Employee feedback: A survey conducted among the employees highlighted the desire for a more flexible work schedule and a better work-life balance. The majority of the respondents expressed interest in a 4-day workweek.
2. Research findings: Studies on companies that have implemented a 4-day workweek have shown increased employee productivity, reduced absenteeism, and improved work-life balance.
3. Competitive advantage: Offering a 4-day workweek can be an attractive benefit to potential employees and can help retain existing talent.
4. Organizational goals: The switch to a 4-day workweek aligns with our organizational goals to create a healthier and more productive work environment.
## Implementation Plan
The following steps will be taken to implement the 4-day workweek:
1. Communication: The decision will be communicated to all employees via a company-wide email and a meeting with team leaders.
2. Schedule: The new schedule will be Monday to Thursday for full-time employees, with the option of flexible schedules for part-time employees. Work hours will be extended to 10 hours per day.
3. Policy updates: Human resources policies, such as leave policies and benefits, will be updated to align with the new schedule.
4. Training: Managers will be trained on how to manage teams under the new schedule and how to properly track employee performance and productivity.
5. Evaluation: The new work schedule will be evaluated after six months to determine its impact on employee satisfaction, engagement, and retention.
## Anticipated outcomes
The implementation of a 4-day workweek is expected to result in the following outcomes:
1. Increased employee satisfaction, engagement, and retention.
2. Improved work-life balance for employees.
3. Increased productivity and reduced absenteeism.
4. More attractive employee benefit package and a competitive advantage in the hiring market.
## Conclusion
We believe that the implementation of a 4-day workweek will benefit our organization and our employees. We look forward to seeing the positive impact of this decision on our employees and our overall organizational performance.
================================================
FILE: locales/en/examples/agile-software-development/.locale-peer-id
================================================
a4bc089ce8e95a6dce0fb0845081674a
================================================
FILE: locales/en/examples/agile-software-development/index.md
================================================
# Decision record for agile software development
Title Introduction of Agile Software Development
Date: [Insert Date]
Team Members Present: [Insert Names]
## Background
The Team has been considering the adoption of Agile software development methodology to increase productivity, improve efficiency, and better adapt to the rapidly changing software development industry.
Key Points:
- Agile emphasizes iterative development, frequent communication, and flexibility in requirements
- Agile can lead to better collaboration among team members
- Agile can help anticipate and respond to changes in project scope and requirements
- Agile can lead to improved time-to-market and better overall project outcomes
## Decision
After much deliberation and discussion, the Team has decided to adopt Agile software development methodology.
## Reasoning
We believe that Agile will help us better adapt to the rapidly changing software development industry and help us deliver high-quality products to our customers. Our decision to adopt Agile was based on an assessment of our current workflow, discussions with industry experts, and our long-term organizational goals.
## Action Items
- Assess team member familiarity with Agile methodology and provide necessary training and resources as required
- Develop and communicate Agile-based project management processes and workflows
- Establish key performance indicators (KPIs) to track the effectiveness of the Agile methodology
- Monitor progress towards KPIs to evaluate the effectiveness of the new Agile methodology
## Conclusion
The adoption of Agile software development methodology is an important decision for our team. We believe that our transition to Agile will help us deliver better products efficiently and effectively.
================================================
FILE: locales/en/examples/amazon-web-services/.locale-peer-id
================================================
c4beaa505311198b2b00341fe42c948f
================================================
FILE: locales/en/examples/amazon-web-services/index.md
================================================
# Architecture Decision Record for Amazon Web Services
Title: Adopting Amazon Web Services for Cloud Infrastructure
## Decision
After a thorough evaluation of various cloud infrastructure platforms, it has been decided that Amazon Web Services (AWS) will be adopted by our organization for our cloud infrastructure needs.
## Background
Our organization is growing rapidly and we need a reliable and scalable cloud infrastructure to meet the demands of our business. After considering a number of cloud infrastructure providers, it was concluded that AWS offers the most suitable range of services to meet our current and future requirements.
## Considerations
There are numerous cloud infrastructure providers in the market that have proven to be reliable and efficient. However, AWS not only offers a comprehensive set of services to cater to our needs, but it also has an extensive customer base and a track record of successful deployments. AWS also provides a broad range of support and training resources to ensure that our team can work effectively with the platform.
Furthermore, AWS has an extensive global presence with data centers located in various regions around the world. This ensures that our data is secure and our applications and services will be highly available. AWS also has a robust security framework that is critical for our business.
Lastly, AWS provides a pay-as-you-go model which offers us the flexibility to scale our infrastructure based on demand. This means that we will only be charged for what we use, which allows us to optimize our costs and invest in other areas of the business.
## Decision
Based on the evaluations performed and the advantages offered by AWS, it has been decided that AWS will be adopted for our cloud infrastructure needs.
## Consequences
The adoption of AWS may require training for our teams to ensure that they are familiar with the platform and can effectively utilize it. There may also be some initial costs to move our current infrastructure to the AWS platform.
## Ownership
The responsibility for ensuring the effective utilization of AWS and the management of associated risks will fall within the remit of the cloud infrastructure team. Any issues that arise must be addressed by this team.
## Review
The decision to adopt AWS will be reviewed on an annual basis to ensure that it continues to meet our needs and that the benefits of the platform are being fully realized.
================================================
FILE: locales/en/examples/api-using-json-v-grpc/.locale-peer-id
================================================
7c91a4cc326aecb7f1a62a6d41b8b4fd
================================================
FILE: locales/en/examples/api-using-json-v-grpc/index.md
================================================
# Architecture Decision Record: API using JSON v. gRPC
## Status
Accepted
## Context
We are designing an API for a new service that will be used by multiple clients. We have been considering two options for implementing the API: using JSON over HTTP or using gRPC.
JSON over HTTP is a widely-used approach for building APIs, and it is supported by many programming languages and frameworks. This approach is simple, lightweight, and easy to understand, making it a good choice for many projects. However, it can be less efficient than other options, especially when it comes to handling large amounts of data.
gRPC, on the other hand, is a newer technology that offers a more efficient way of building APIs. It uses binary serialization to transfer data, which can be faster and more compact than using JSON. gRPC also supports bidirectional streaming, making it a good choice for real-time applications.
## Decision
After considering the pros and cons of both options, we have decided to use gRPC for our API. Although JSON over HTTP is a simpler option, we believe that gRPC will provide a more efficient and scalable solution for our service. We also anticipate that our API will handle a large amount of data, and gRPC's binary serialization will be more efficient for this use case.
In addition, we believe that gRPC's support for bidirectional streaming will be beneficial for real-time applications that we may develop in the future.
## Consequences
By choosing gRPC, we will need to use a different set of tools and libraries to build our API compared to using JSON over HTTP. This may require additional time and effort to learn and implement these technologies. Additionally, clients who want to use our API will need to use gRPC-compatible libraries, which may not be as widely supported as JSON over HTTP libraries.
However, we believe that the benefits of using gRPC outweigh these potential drawbacks, and we are confident that this decision will result in a more efficient and scalable API.
================================================
FILE: locales/en/examples/authentication-authorization-options/index.md
================================================
# Architecture Decision Record: authentication authorization options
<!--
ChatGPT prompt:
Explain web application authentication authorization.
Describe: OAuth, OpenID Connect, SAML, WS-Federation, LDAP, Social SSO Providers.
-->
Web application authentication and authorization are two crucial concepts in securing access to applications and services. Both deal with the identity of users and how permissions are granted, but they focus on different aspects:
- **Authentication** is the process of verifying the identity of a user or system.
- **Authorization** is the process of determining what resources or actions the authenticated user or system can access.
Now, let's dive into the specific protocols and technologies you've mentioned, which are commonly used in modern web applications for managing authentication and authorization.
### 1. **OAuth (Open Authorization)**
**OAuth** is an open standard for authorization. It allows a user to grant a third-party application limited access to their resources without sharing their credentials. The key idea is **delegated access**. OAuth is often used in situations where users can log in to a third-party service (e.g., signing in with Google) without directly providing their username and password to the third-party.
- **Flow**: OAuth typically follows a **token-based** flow, where an authorization server issues an access token to the third-party application. This token represents the user's permissions, and the application uses it to access the user's data or resources from an API.
- **Example**: A user signs into a third-party app using their Google account. Google verifies the user's identity and then grants a token that allows the third-party app to access some Google data (e.g., Google Calendar).
OAuth **does not** handle authentication directly; it’s about granting access. For authentication, OAuth is often paired with other protocols, like **OpenID Connect**.
### 2. **OpenID Connect (OIDC)**
**OpenID Connect (OIDC)** is an identity layer built on top of **OAuth 2.0** that adds authentication to OAuth’s authorization capabilities. Essentially, OpenID Connect extends OAuth to handle **user authentication** and provides a standardized way for applications to verify the identity of a user.
- **Flow**: When a user logs in using OpenID Connect, the third-party application requests an ID token (in addition to the OAuth access token). The ID token contains information about the user (such as their username, email, and other claims). This allows the application to know who the user is and whether they are authenticated.
- **Example**: Logging into a service like Slack using your Google account (Google being the OpenID Connect provider) involves authentication via OpenID Connect, while OAuth manages the access to your Google resources.
OIDC makes it easier for third-party apps to **authenticate users** while still allowing fine-grained control over what resources those apps can access.
### 3. **SAML (Security Assertion Markup Language)**
**SAML** is an older, XML-based standard used for exchanging authentication and authorization data between parties, particularly in **Single Sign-On (SSO)** scenarios. It's primarily used in enterprise environments to enable users to authenticate once and access multiple applications without re-entering credentials.
- **Flow**: The user first authenticates with an identity provider (IdP). The IdP generates a signed **SAML assertion** that includes the user's identity and related attributes. The assertion is sent to the service provider (SP), which uses it to authorize access to the application.
- **Example**: An employee logs into their corporate portal (the IdP) and is automatically logged into other systems like email, CRM, etc., without re-entering credentials. The authentication process is based on the SAML assertion sent by the IdP.
SAML is commonly used in **enterprise SSO solutions** and works well for web applications in corporate environments, but it’s less mobile-friendly compared to OAuth/OIDC.
### 4. **WS-Federation (Web Services Federation)**
**WS-Federation** is another protocol used for **Single Sign-On (SSO)**, especially in Microsoft-based enterprise environments. It's part of the **WS-* (Web Services)** family of specifications and allows for identity federation across different security domains (such as between different organizations or between different services).
- **Flow**: WS-Federation allows a **trusted identity provider (IdP)** to authenticate users and issue tokens that the service provider can use for authorization. It’s similar to SAML but is often used in scenarios that rely heavily on Microsoft technologies.
- **Example**: A user logs into an enterprise application hosted by Microsoft Azure Active Directory (AD), and their identity can be used to access other federated services, including applications hosted by third-party vendors.
Although WS-Federation is largely replaced by newer protocols like OAuth2.0 and OpenID Connect in many modern web environments, it’s still used in legacy systems, especially in Microsoft-centric enterprises.
### 5. **LDAP (Lightweight Directory Access Protocol)**
**LDAP** is a protocol used to access and manage directory services, commonly used for **storing user credentials** and managing access control in a centralized directory (often called a **Directory Service**). LDAP isn't specifically about authentication or authorization but is used to store and retrieve identity data, which is then used in those processes.
- **Authentication**: LDAP allows an application to authenticate users by querying the directory service for credentials (like passwords).
- **Authorization**: It also manages user roles and permissions, helping determine whether a user has access to certain resources.
- **Example**: Many enterprises use LDAP-based directories (e.g., **Active Directory**) for authentication and authorization, especially within Windows environments.
LDAP is crucial for enterprises to manage user access across internal systems, but in a modern web context, LDAP is often integrated with other protocols like SAML or OAuth for more complete identity management.
### 6. **Social SSO Providers**
Social **Single Sign-On (SSO)** providers like **Facebook**, **Google**, **Twitter**, **GitHub**, and others allow users to authenticate into third-party applications using their social media credentials. This is a type of **OAuth-based authentication** where the third-party service (e.g., Google) is the identity provider.
- **Flow**: The user clicks "Log in with Google" (for example). The app redirects to Google, where the user logs in (if not already logged in). Google then provides an access token or ID token to the third-party app, which can be used to authenticate the user and possibly access their data.
- **Example**: Many applications allow you to log in using your Google or Facebook credentials. The app will use OAuth or OpenID Connect behind the scenes to verify your identity and, in some cases, access certain social media data.
Social SSO is a convenient and widely adopted method for authentication because it reduces friction for users, who may not want to create yet another username and password.
---
### Summary of Differences:
- **OAuth**: Used for authorization, allows third-party apps to access user data without exposing credentials.
- **OpenID Connect**: Extends OAuth to provide authentication, enabling apps to verify user identity.
- **SAML**: XML-based protocol used for SSO, often in enterprise environments.
- **WS-Federation**: A Microsoft-specific protocol for identity federation, used in legacy systems.
- **LDAP**: A protocol for querying directory services to authenticate users and manage authorization.
- **Social SSO Providers**: OAuth-based systems (like Google, Facebook) that allow third-party apps to authenticate users using their social media credentials.
Each of these technologies has its own strengths and use cases, and in modern applications, you may see a combination of them being used for different aspects of security (e.g., OAuth/OIDC for API access, SAML for enterprise SSO).
================================================
FILE: locales/en/examples/browser-automation-framework-for-e2e-testing-playwright-vs-selenium/index.md
================================================
## Architecture decision record: browser automation framework for E2E testing (Playwright vs Selenium)
### 1. **Context**
We are in the process of selecting a browser automation framework for our end-to-end (E2E) testing pipeline. This framework will be integral to our CI/CD processes, running tests that simulate real user interactions on our platform. Specifically, the tests will cover scenarios such as user sign-up/sign-in, file uploads, dashboard interactions, and report downloads.
As a **startup**, our focus is on **agile development**, with a need to rapidly iterate and evolve. Our team predominantly works with **TypeScript** and **Python**, and the ability to write tests in these languages is essential. Additionally, the platform contains **interactive charts and dashboards**, which makes it critical that the automation tool supports rich, dynamic UIs well.
The two contenders for this task are **Playwright** and **Selenium**, each with its strengths and trade-offs. We need to evaluate these frameworks based on the features and requirements outlined below.
### 2. **Considered Options**
- **Playwright** (by Microsoft)
- **Selenium** (by the Selenium Project)
### 3. **Decision Drivers**
The factors influencing our decision are as follows:
1. **Agile Development**: The chosen tool must enable fast, flexible development cycles.
2. **Language Support**: Our team requires support for both **TypeScript** and **Python**.
3. **Interactive UI Testing**: The ability to test interactive charts, dashboards, and dynamic elements reliably is essential.
4. **Runtime Speed**: While not a primary concern, performance in CI/CD pipelines is a consideration.
5. **Scalability**: We are not planning for massive scaling in the immediate future, but we want to ensure the solution can handle future growth.
6. **Backwards Compatibility**: Legacy systems and compatibility with older browsers are not critical for our project at this time.
7. **Mobile Testing**: While not an immediate focus, the framework should be capable of testing mobile-responsive features or be extensible for such use cases.
8. **Multi-monitor Testing**: Support for multi-monitor configurations is a secondary requirement, especially if we ever scale to testing for more complex user workflows.
9. **File Upload Testing**: The framework must handle file uploads efficiently, a core requirement of our testing needs.
### 4. **Evaluation Criteria**
- **Ease of Use**: How easy is it to write and maintain tests?
- **Language Support**: Does the framework support TypeScript and Python, the two languages our team uses most frequently?
- **Interactive UI Testing**: How well does the framework handle complex, interactive user interfaces such as charts, file uploads, and dynamic data?
- **CI/CD Integration**: How well does the framework integrate into common CI/CD tools and services?
- **Cross-browser Support**: What browsers are supported and how well do they perform?
- **Performance and Speed**: How quickly do tests run, especially in a CI/CD pipeline?
- **Scalability**: How well can the framework scale if more tests or more complex scenarios are added?
- **Community and Ecosystem**: How active is the framework's community? Are there plenty of integrations and extensions available?
### 5. **Considerations**
#### 5.1 **Playwright**
##### **Pros**:
1. **Smarter API for Local File Uploads**: Playwright’s API for interacting with local files and performing file uploads is simpler and more intuitive. This would make file upload testing easier to implement and maintain.
2. **Syntax and Code Generation**: Playwright has a shorter, more concise syntax. This results in less boilerplate code, which improves maintainability and developer efficiency. Additionally, this shorter syntax improves OpenAI code generation quality, making it easier to automatically generate test scripts.
3. **Interactive UI Testing**: Playwright excels at testing dynamic, interactive web applications, such as those with rich charts, complex user interactions, and real-time updates. It handles WebSockets, WebRTC, shadow DOMs, and other modern web technologies very effectively.
4. **Cross-browser Support**: Playwright supports **Chromium**, **WebKit**, and **Firefox**. It has consistent performance across these browsers, which should cover most of our testing needs.
5. **CI/CD Integration**: Playwright integrates seamlessly with modern CI/CD platforms (GitHub Actions, Jenkins, etc.). It can run tests in parallel across different browsers, optimizing test run times and making it suitable for rapid development.
6. **Fast and Reliable**: Playwright is faster than Selenium in general, especially in headless mode, and more resilient when dealing with asynchronous web elements.
##### **Cons**:
1. **Limited Mobile Testing**: While Playwright does support mobile emulation for browsers, it lacks native mobile testing capabilities like Selenium’s integration with Appium for true mobile testing.
2. **Smaller Ecosystem**: Playwright is still newer and less established than Selenium. While it has a rapidly growing community and good documentation, it might not yet have the vast ecosystem of plugins and integrations that Selenium offers.
3. **Limited Browser Support**: While Playwright covers the major modern browsers (Chrome, Safari, Firefox), its support for legacy browsers (e.g., Internet Explorer) is not as robust as Selenium’s.
#### 5.2 **Selenium**
##### **Pros**:
1. **Longer History and Maturity**: Selenium has been around for a long time and has a proven track record. It’s widely used across many teams and industries, which has led to a vast ecosystem of plugins, integrations, and resources.
2. **Cross-browser and Cross-platform Support**: Selenium supports a **wide variety of browsers** and versions, including **Internet Explorer**, and can also be integrated with various tools like **Docker**, **Selenium Grid**, and **cloud services** for distributed testing.
3. **Mobile Testing**: Selenium, through its integration with **Appium**, is much more robust for mobile testing, including both Android and iOS applications. This makes it the better choice for projects with a mobile-first or mobile-heavy focus.
4. **Multi-monitor Testing**: Selenium provides better support for scenarios involving **multiple monitors** or complex multi-window interactions.
##### **Cons**:
1. **Complexity**: Selenium’s API is more verbose and explicit. While this can be an advantage in some cases, it means more code to write and maintain, which may reduce developer agility—especially important in a startup environment.
2. **Performance**: Selenium generally runs slower than Playwright, especially in headless mode. This could impact CI/CD pipelines, particularly as the number of tests grows.
3. **Interactive UI Testing**: Selenium is not as smooth as Playwright when it comes to testing modern, interactive web UIs, particularly with charts and real-time data updates. It requires more setup and handling to reliably interact with dynamic content.
### 6. **Comparison Summary**
| Feature | Playwright | Selenium |
|-----------------------------------|-----------------------------------------------|-------------------------------------------|
| **Ease of Use** | Shorter syntax, more intuitive for modern UIs | More explicit, requires more boilerplate |
| **Language Support** | TypeScript, Python, JavaScript | TypeScript, Python, Java, Ruby, C# |
| **Interactive UI Testing** | Excellent for dynamic, real-time UIs | Handles basic UIs, but more verbose and complex for rich interactions |
| **File Upload Testing** | Smarter API for file uploads | More verbose, less intuitive API |
| **CI/CD Integration** | Easy integration with GitHub Actions, Jenkins | Strong integration with many CI tools |
| **Mobile Testing** | Limited, only emulation | Full support through Appium |
| **Cross-browser Support** | Chromium, WebKit, Firefox | Full support across major and legacy browsers |
| **Performance** | Fast, optimized for headless testing | Slower, especially in headless mode |
| **Multi-monitor Testing** | Limited | Good support for multi-monitor setups |
| **Community and Ecosystem** | Growing, good documentation | Large, mature, extensive ecosystem |
### 7. **Decision**
After considering the requirements and trade-offs, **Playwright** is the better choice for our current needs. Its smarter API for local file upload testing, concise syntax, and strong support for interactive UI testing make it an ideal fit for our agile development cycle. The fact that it supports both **TypeScript** and **Python** is critical for our team, and the framework's modern approach to testing will allow us to write clean, maintainable code.
While **Selenium** remains a great tool, particularly for mobile testing, legacy browser support, and multi-monitor setups, it is less well-suited to our current needs. Its verbosity, slower performance, and more complex handling of dynamic UIs like charts make it less optimal for our use case.
### 8. **Consequences**
- **Immediate Action**: We will adopt **Playwright** for our E2E testing, focusing on testing user flows involving sign-up, sign-in, file uploads, dashboards, and report downloads.
- **Long-Term Considerations**: We will keep an eye on the evolving Playwright ecosystem. If our needs change, particularly around mobile testing or support for legacy browsers, we may revisit Selenium.
- **Training and Documentation**: Development teams will need to become familiar with Playwright's API, particularly for handling dynamic UIs and file uploads.
- **Migration**: Existing Selenium tests (if any) will be gradually migrated to Playwright.
### 9. **Future Considerations**
================================================
FILE: locales/en/examples/chart-library-toolkit-for-data-visualization-using-typescript-and-json/index.md
================================================
# Architecture Decision Record: chart library toolkit for data visualization using TypeScript and JSON
<!--
ChatGPT prompt:
Long software architecture decision record
chart library toolkit for data visualization using TypeScript and JSON
Evaluate Charts: Apache ECharts, Chart.js, ApexCharts, AG Charts, Highcharts, Carbon Charts, Layer Cake, D3.
Primary need: advanced interactive charts, especially for financial data, scientific data, and government data.
High importance: 1. Agile development because this is for a startup. 2. Doughnut Chart, Radar Chart, Clustering Process
Chart, Area Chart with Time Axis, Candlestick Chart, Nightingale Chart, Geo SVG Map. 3. Free open source.
Low importance: 1. Runtime speed. 2. Scalability. 3. Backwards compatibility.
-->
**Primary Objective:**
To select an advanced charting toolkit for creating interactive visualizations, focusing on financial data, scientific data, and government data using TypeScript and JSON. The library should provide robust features, flexibility, and be open-source.
### Context and Requirements:
1. **Agile Development (High Priority)**: As a startup, quick iteration, prototyping, and flexibility in development are essential. The chart library must allow for fast development cycles.
2. **Chart Types (High Priority)**:
- **Doughnut Chart**
- **Radar Chart**
- **Clustering Process Chart**
- **Area Chart with Time Axis**
- **Candlestick Chart**
- **Nightingale Chart**
- **Geo SVG Map**
These chart types are specifically important for visualizing complex datasets, such as financial trends, scientific metrics, and geographical information.
3. **Free and Open Source (High Priority)**: The toolkit should be open-source to avoid licensing costs, provide transparency, and offer flexibility for customization.
4. **Low Importance Criteria**:
- **Runtime Speed**: While performance is important, it is not a top priority for this decision.
- **Scalability**: Although scalability is generally important, the immediate need is to build an MVP that may grow over time. Scalability concerns can be addressed later.
- **Backwards Compatibility**: Not a primary concern for the initial build, as long as the library is modern and actively maintained.
### Libraries Evaluated:
1. **Apache ECharts**
2. **Chart.js**
3. **ApexCharts**
4. **AG Charts**
5. **Highcharts**
6. **Carbon Charts**
7. **Layer Cake**
8. **D3.js**
---
### 1. **Apache ECharts**
**Overview**:
Apache ECharts is a powerful, flexible charting library for interactive, customizable visualizations. It provides support for a wide variety of charts and is particularly strong in complex, dynamic visualizations.
**Strengths**:
- **Advanced Interactivity**: ECharts excels in providing interactive charts, offering features like zooming, panning, and dynamic data updates.
- **Doughnut, Radar, Candlestick, Geo SVG Maps**: ECharts supports many of the required chart types, including doughnut, radar, candlestick, and geographical map visualizations.
- **Free and Open Source**: ECharts is an open-source library, which fits the budget-conscious nature of a startup and provides freedom to modify the code.
- **Flexibility and Extensibility**: Highly customizable, with extensive support for animations, custom visualizations, and advanced charting techniques.
**Weaknesses**:
- **Learning Curve**: ECharts, while powerful, can have a steeper learning curve due to its flexibility and extensive API.
- **Documentation Complexity**: The documentation is comprehensive but can be overwhelming for developers just starting out with it.
**Verdict**:
ECharts is highly suitable for the project due to its support for interactive charts, including all the required types like candlestick charts, radar charts, and geo maps. Its open-source nature aligns with the project's need for flexibility and cost-effectiveness.
---
### 2. **Chart.js**
**Overview**:
Chart.js is a simple, easy-to-use charting library for building common chart types. It’s known for its simplicity and ease of integration.
**Strengths**:
- **Ease of Use**: Chart.js is very simple to set up and use, with a minimal learning curve.
- **Open Source**: Chart.js is free and open-source, which is critical for reducing costs.
- **Common Chart Types**: It supports basic charts like doughnut, area, radar, and line charts, which cover most of the primary needs.
**Weaknesses**:
- **Limited Advanced Charts**: Chart.js does not natively support complex chart types like candlestick charts, geo SVG maps, or clustering process charts. While these features can be added through plugins or customization, it is not as straightforward as with other libraries.
- **Interactivity**: Although Chart.js supports basic interactivity (e.g., tooltips and hover effects), it does not offer as advanced features as ECharts or D3.js.
**Verdict**:
Chart.js is great for simple, quick projects, but its lack of support for complex chart types makes it unsuitable for a data-heavy application with advanced needs like candlestick charts and geo maps. It’s a good choice for prototyping, but for the required chart types, more advanced tools are recommended.
---
### 3. **ApexCharts**
**Overview**:
ApexCharts is a modern charting library that provides a variety of chart types and focuses on interactive visualizations with an easy-to-use API.
**Strengths**:
- **Interactive Features**: ApexCharts offers interactive charts with tooltips, zooming, panning, and updates.
- **Support for Financial and Scientific Charts**: It supports a wide variety of chart types, including candlestick charts, radar charts, and area charts.
- **Ease of Use**: It has a straightforward API and is simple to integrate into a project.
- **Free and Open Source**: ApexCharts offers a free open-source version that is suitable for many use cases.
**Weaknesses**:
- **Complex Customization**: While it provides many features, the customization options are not as flexible as ECharts or D3.js for highly complex or custom charting needs.
- **Geo Maps**: ApexCharts does not natively support geo maps or clustering process charts, which are required for this project.
**Verdict**:
ApexCharts is a strong contender due to its ease of use and interactivity, but it falls short on certain advanced chart types, particularly the need for geo maps and clustering charts. It’s a good option for simpler charts but lacks some required features.
---
### 4. **AG Charts**
**Overview**:
AG Charts is a commercial-grade charting library designed for performance and precision. It is highly suitable for creating financial, scientific, and business dashboards.
**Strengths**:
- **Advanced Chart Types**: AG Charts supports many advanced chart types, including candlestick charts, area charts, radar charts, and more. It also offers deep integration with other AG-Grid products.
- **High Performance**: It offers excellent performance, especially when dealing with large datasets.
- **Interactivity**: AG Charts supports a variety of interactive features like zooming, tooltips, and dynamic updates.
**Weaknesses**:
- **Not Fully Free**: While AG Charts offers a free version, the full-featured version is paid, which could be a barrier for startups looking to minimize costs.
- **Complexity**: While the library is feature-rich, it may be overkill for simpler projects and can require more setup and configuration compared to other options.
**Verdict**:
AG Charts is powerful and feature-rich but may not be the best fit due to its commercial nature and cost structure. Its suitability depends on whether the budget can accommodate paid versions or if open-source alternatives are preferred.
---
### 5. **Highcharts**
**Overview**:
Highcharts is a popular charting library known for its wide range of chart types and powerful customization options.
**Strengths**:
- **Comprehensive Chart Types**: Highcharts supports a wide variety of charts, including candlestick, radar, area, and geo maps.
- **Interactive and Dynamic**: Highcharts provides rich interactive features, including drill-downs, zooming, and panning.
- **Ease of Use**: It has a user-friendly API and good documentation, making it easy to get started.
**Weaknesses**:
- **Commercial License**: While Highcharts offers a free version for non-commercial use, the commercial license is expensive, which could be a significant drawback for startups.
- **Learning Curve**: Although not as steep as ECharts, the learning curve for Highcharts can still be challenging for beginners.
**Verdict**:
Highcharts is a feature-rich library, but its commercial licensing makes it less suitable for open-source, cost-sensitive projects. Its comprehensive charting options are a plus, but the licensing issue limits its appeal for this use case.
---
### 6. **Carbon Charts**
**Overview**:
Carbon Charts is a charting library developed by IBM, designed for creating visually appealing and highly customizable charts.
**Strengths**:
- **Customizability**: Carbon Charts allows for extensive customization of chart appearance and behavior.
- **Open Source**: It is free and open-source, which aligns with the project’s requirement for budget-friendly solutions.
- **Support for Common Charts**: It supports common chart types like doughnut, radar, and area charts, though it lacks support for more advanced types like geo maps or candlestick charts.
**Weaknesses**:
- **Limited Advanced Chart Types**: It does not support geo maps, clustering process charts, or candlestick charts, which are essential for the project.
- **Smaller Ecosystem**: Carbon Charts has a smaller community and ecosystem compared to larger chart libraries like ECharts or Highcharts.
**Verdict**:
Carbon Charts is open-source and customizable but lacks support for the more complex chart types needed for this project. It is more suitable for simpler charting needs.
---
### 7. **Layer Cake**
**Overview**:
Layer Cake is a data visualization library designed for creating flexible, layered visualizations.
**Strengths**:
- **Customizable Layers**: It provides powerful layering options for complex visualizations.
- **Open Source**: It’s free and open-source, making it a viable option for budget-conscious projects.
**Weaknesses**:
- **Limited Documentation**: Layer Cake lacks extensive documentation and community support, making it more difficult to work with compared to more established libraries.
- **Not Built for Charts**: Layer Cake is better suited for non-chart visualizations, so its out-of-the-box charting options are limited.
**Verdict**:
While interesting for unique visualizations, Layer Cake is not ideal for traditional charting requirements like candlestick charts or radar charts. It’s more suited for custom visualizations outside the scope of standard charts.
---
### 8. **D3.js**
**Overview**:
D3.js is a powerful JavaScript library for creating data-driven visualizations through HTML, SVG, and CSS.
**Strengths**:
- **Unmatched Flexibility**: D3.js allows for creating virtually any type of custom visualization, making it highly powerful for advanced and interactive charts.
- **Extensive Features**: It supports all chart types required, including geo maps, clustering charts, and more.
- **Customizable**: The level of customization in D3.js is unparalleled, allowing developers to build highly tailored visualizations.
**Weaknesses**:
- **Steep Learning Curve**: D3.js has a steep learning curve and is more complex to integrate compared to other libraries.
- **Time-Consuming**: Building charts in D3.js can be time-consuming, especially for common charts like candlestick or doughnut charts.
**Verdict**:
D3.js is incredibly powerful for advanced, customized charts but is overkill for many typical use cases due to its steep learning curve and development time. It’s best for situations where the other chart libraries do not provide the required level of customization.
---
### Conclusion
After evaluating the libraries based on the project’s needs, **Apache ECharts** stands out as the best option. It supports the full range of required charts, including geo maps, candlestick charts, and clustering charts. It’s open-source, feature-rich, and highly interactive, which aligns perfectly with the project's goals. While **D3.js** offers the most flexibility, its complexity and time investment make it less ideal for a startup looking to iterate quickly. **ApexCharts** and **Chart.js** are good alternatives for simpler projects but lack support for advanced chart types.
================================================
FILE: locales/en/examples/choosing-a-database-technology/.locale-peer-id
================================================
ee24129d8750e5ceebb9b4ff7b3cfb1a
================================================
FILE: locales/en/examples/choosing-a-database-technology/index.md
================================================
# Architecture Decision Record: Choosing a Database Technology
## Status
Accepted
## Context
We are designing a new application that requires storing and retrieving data in a scalable and performant manner. We have identified three types of database technologies that are commonly used: relational databases, document databases, and event databases.
Relational databases store data in tables with fixed schemas and enforce strict data integrity constraints. They are suitable for applications that require complex data relationships and transactions. Examples include MySQL, PostgreSQL, and Oracle.
Document databases store data in JSON-like documents and are schema-less. They are well-suited for applications that require flexible data models and scaling horizontally. Examples include MongoDB, Couchbase, and Amazon DynamoDB.
Event databases store data as a series of events, capturing every change to the data. They are suitable for applications that require auditing, event sourcing, and complex data processing. Examples include Apache Kafka, Apache Pulsar, and AWS Kinesis.
Decision
After carefully evaluating the requirements and constraints of our application, we have decided to use a document database.
## Rationale
We have chosen a document database because:
1. Our application requires a flexible data model that can evolve over time. Document databases allow us to store data in a schema-less format, which means we can add new fields or change the structure of existing documents without having to modify the database schema.
2. Our application needs to scale horizontally to handle large volumes of data and traffic. Document databases provide built-in support for sharding and replication, which enables us to distribute data across multiple servers and handle high read and write throughput.
3. Our application requires fast and efficient data retrieval. Document databases provide powerful indexing and querying capabilities that enable us to retrieve data quickly and efficiently.
4. Our application does not require complex transactions or data relationships. While relational databases excel at enforcing data integrity constraints and handling complex transactions, our application does not have such requirements. Document databases can provide sufficient consistency and durability guarantees for our use case.
## Consequences
By choosing a document database, we will need to invest in learning and understanding the specific technology we choose to use. Additionally, we will need to ensure that our application's data model fits well with the document database's data model to maximize performance and scalability.
However, we believe that the benefits of using a document database outweigh the costs, and that it is the best fit for our application's requirements and constraints.
================================================
FILE: locales/en/examples/continuous-integration/.locale-peer-id
================================================
45cdbd2e37d773b7e0592a142fd5de30
================================================
FILE: locales/en/examples/continuous-integration/index.md
================================================
# Decision Record for continuous integration
Title: Decision to Implement Continuous Integration
## Context
The company has been experiencing challenges with the development process as a result of manual testing, build processes, and deployments. This has led to frequent delays, errors and inconsistencies in the quality and delivery of the software.
## Decision
To implement continuous integration as a solution to the challenges experienced in the development process.
## Rationale
Continuous integration will automatically build, test and deploy code changes to the delivery environment in a timely and efficient manner. It will enable integration of new features into the codebase without interfering with the stability of the software. Continuous integration will enhance the quality and delivery of the software, reduce the time taken to resolve errors and improve stakeholder satisfaction.
## Consequences
Positive:
- Improved quality and delivery of software
- Time and cost savings through automation
- Enhanced collaboration and integration within the development team
Negative:
- Initial costs associated with implementing the technology
- Upfront investment in people, tools and processes required to implement continuous integration
- Potential risk of technical difficulties during the implementation.
## Conclusion
The benefits of implementing continuous integration outweigh the costs of investment and the potential risks. Therefore, the decision to implement continuous integration has been approved.
================================================
FILE: locales/en/examples/css-framework/.locale-peer-id
================================================
694d2d4235299f058990c1cc470af15e
================================================
FILE: locales/en/examples/css-framework/index.md
================================================
# Architecture Decision Record: CSS framework
Contents:
- [Summary](#summary)
- [Issue](#issue)
- [Decision](#decision)
- [Status](#status)
- [Details](#details)
- [Assumptions](#assumptions)
- [Constraints](#constraints)
- [Positions](#positions)
- [Argument](#argument)
- [Implications](#implications)
- [Related](#related)
- [Related decisions](#related-decisions)
- [Related requirements](#related-requirements)
- [Related artifacts](#related-artifacts)
- [Related principles](#related-principles)
- [Notes](#notes)
## Summary
### Issue
We want to use a CSS framework to create our web applications:
* We want user experience to be fast and reliable, on all popular browsers and screen sizes.
* We want rapid iteration on design, layout, UI/UX, etc.
* We want responsive applications, especially for smaller screens such as on mobile devices, larger screens such as on 4K widescreens, and dynamic screens such as rotatable displays.
### Decision
Decided on Bulma.
### Status
Decided on Bulma. Open to new CSS framework choices as they arrive.
## Details
### Assumptions
We want to create web apps that are modern, fast, reliable, responsive, etc.
Typical modern web apps are reducing/eliminating the use of jQuery because of multiple reasons:
* Modern JavaScript is phasing in many capabilities that jQuery has provided, so jQuery is less needed, and there are better/faster/smaller modules that provide specific implementations
* jQuery's broad approach is to do direct DOM manipulation, which is an anti-pattern for modern JavaScript frameworks (e.g. React, Vue, Svelte)
* jQuery interferes with itself if it's loaded twice, etc.
### Constraints
If we choose a CSS framework that uses jQuery, then we're stuck importing jQuery. For example, Semantic UI uses jQuery, and Tachyons does not.
If we choose a CSS framework that is minimal, then we forego framework components that we may want now or soon. For example, Semantic UI provides an image carousel, and Tachyons does not.
### Positions
We considered using no framework. This still seems viable, especially because CSS grid provides much of what we need for our project..
We considered many CSS frameworks using a quick shortlist triage: Bootstrap, Bulma, Foundation, Materialize, Semantic UI, Tachyons, etc. Our two selections for deeper review are Semantic UI (because it has the most-semantic approach) and Bulma (because it has the lightest-weight approach that provides the components we want now).
We considered Semantic UI. This provides many components, including ones we want for our project: tabs, grids, buttons, etc. We did a pilot with Semantic UI two ways: using typical CDN files, and using NPM repos. We achieved success with Semantic UI in a static HTML page, but did not achieve success within our timebox to build a JavaScript SPA (primarily because of jQuery load issues). We discovered that other coders have been asking the Semantic UI developers to create a jQuery-free version, for the same reasons we have. Other coders have been requesting a jQuery-free version for many years, yet the developers have said no, and stated that any jQuery-free version would be too hard to write e.g. ~"the Semantic UI project has more than 22,000 touchpoints that use jQuery".
Example with Semantic:
```html
<div class="ui top attached tabular menu">
<a class="item">Alpha</a>
<a class="item">Bravo</a>
</div>
```
We considered Bulma. Bulma has many similar capabilities as Semantic UI, although not as many sophisticated components. Bulma is built with modern techniques, such as no jQuery. Bulma has some third-party components, some of which we may want to use.
Example with Bulma:
```html
<div class="tabs">
<ul>
<li><a>Alpha</a></li>
<li><a>Bravo</a></li>
</ul>
</div>
```
### Argument
As above.
Specifically, Semantic UI seems to have a caution flag both in terms of technology (i.e. so many jQuery touchpoints) and also in terms of leadership (i.e. jQuery-free was a hard no, rather than attempting a roadmap, or continuous improvement, or donation fundraising, etc.).
### Implications
If we find a good non-jQuery CSS framework, this is generally helpful and good overall.
## Related
### Related decisions
The CSS framework we choose may affect testability.
### Related requirements
We want to ship a purely-modern app fast.
We do not want to spend time working on older frameworks (esp. Semantic UI) using older dependencies (esp. jQuery).
### Related artifacts
Affects all the typical HTML that will use the CSS.
### Related principles
Easily reversible.
Need for speed.
## Notes
Any notes here.
================================================
FILE: locales/en/examples/docker-swarm-container-orchestration/.locale-peer-id
================================================
3d27355877340537b28efb2bae3a6907
================================================
FILE: locales/en/examples/docker-swarm-container-orchestration/index.md
================================================
# Architecture Decision Record: Docker Swarm Container Orchestration
Decision Number: 001
Decision Maker: [Your name or position]
Date: [Date of decision]
## Context
We are considering different container orchestration tools to manage our microservices-based architecture. We have evaluated different solutions like Kubernetes, Docker Swarm, and Mesosphere DC/OS. However, we have decided to focus on Docker Swarm due to its simplicity, integration with Docker, and built-in load balancing.
## Decision
We have decided to use Docker Swarm as our container orchestration tool. Docker Swarm provides a simple and intuitive way to manage containerized applications across a cluster of nodes. It also allows us to leverage our existing Docker-based workflows and infrastructure. With Docker Swarm, we can easily deploy, scale, and manage our applications, all while taking advantage of built-in load balancing.
## Benefits
- **Simplicity:** Docker Swarm follows the same principles as Docker, so there's no need to learn a new technology. The learning curve is relatively shallow for developers familiar with Docker.
- **Integration:** Docker Swarm integrates seamlessly with Docker tools, like Docker Compose, making it easier to manage all our containers and services from one place.
- **Load balancing:** Docker Swarm provides built-in load balancing, ensuring that our applications are always available and evenly distributed across the cluster.
- **Scalability:** Docker Swarm makes it easy to scale our applications horizontally by adding or removing nodes from the cluster.
- **High availability:** Docker Swarm automatically distributes our services across nodes, providing high availability in case of node failure.
## Risks
- **Limited functionality:** Docker Swarm may lack some of the advanced features found in Kubernetes or Mesosphere DC/OS, like automatic scaling or self-healing.
- **Docker-centric:** Docker Swarm is tightly coupled with Docker, which may limit our flexibility if we ever need to move away from Docker-based solutions.
- **Immaturity:** Docker Swarm is still a relatively new technology, and there may be some stability issues or gaps in documentation.
## Alternatives
- **Kubernetes:** Kubernetes is the most widely-used container orchestration platform and provides advanced features and a more mature ecosystem. However, it has a steeper learning curve and may be overkill for our needs.
- **Mesosphere DC/OS:** Mesosphere DC/OS is a powerful tool that provides advanced features like multi-cloud support and native big data and AI platform capabilities. However, it requires significant expertise to implement and may be too complex for our requirements.
## Conclusion
After careful consideration, we have decided to use Docker Swarm as our container orchestration tool. Docker Swarm provides the simplicity, integration, and built-in load balancing we need to manage our containerized applications. Although it may lack some advanced features, we believe Docker Swarm's benefits outweigh its risks for our current requirements.
<h6>Credit: this page is generated by ChatGPT, then edited for clarity and format.</h6>
================================================
FILE: locales/en/examples/environment-variable-configuration/.locale-peer-id
================================================
46b0910941ab1812cda52b34baca5798
================================================
FILE: locales/en/examples/environment-variable-configuration/index.md
================================================
# Environment variable configuration
Contents:
* [Summary](#summary)
* [Issue](#issue)
* [Decision](#decision)
* [Status](#status)
* [Details](#details)
* [Assumptions](#assumptions)
* [Constraints](#constraints)
* [Positions](#positions)
* [Argument](#argument)
* [Implications ](#implications)
* [Related](#related)
* [Related decisions](#related-decisions)
* [Related requirements](#related-requirements)
* [Related artifacts](#related-artifacts)
* [Related principles](#related-principles)
* [Notes](#notes)
## Summary
### Issue
We want our applications to be configurable beyond artifacts/binaries/source, such that one build can behave differently depending on its deployment environment.
* To accomplish this, we want to use environment variable configuration.
* We want to manage the configuration by using files that we can version control.
* We want to provide some developer experience ergonomics, such as knowing what can be configured and any relevant defaults.
### Decision
Decided on .env files with related default file and schema file.
### Status
Decided. Open to considering to new capabilities as they come up.
## Details
### Assumptions
We favor separating the application code and environment code. We assume the app needs to work differently in different environments, such as in a development environment, test environment, demo environment, production environment, etc.
We favor the industry practice of "12 factor app" and even more the related practice of "15 factor app".
Many of our previous projects have used the convention of a `.env` file or similar `.env` directory. There's a typical practice of keeping these out of version control, and instead using some other way to deploy them, version them, and manage them.
### Constraints
We want to keep secrets out of our source code management (SCM) version control system (VCS).
We want to aim for compatibility with popular software frameworks and libraries. For example, Node has a module "dotenv" for reading environment variable configuration.
### Positions
We considered a few approaches:
* Store config in the app such as in a file `config.js` file.
* Store config in the environment such as in a file `.env`.
* Fetch config from a known location such as a license server.
### Argument
We selected the approach of a file .env because:
* It is popular including among experts.
* It follows the pattern of `.env` files which our teams have successfully used many times on many projects.
* It is simple. Notably, We are fine for now with the significant trade-offs that we see, such as a lack of audit capabilities as compared to an approach of a license server.
### Implications
We need to figure out a way to separate environment variable configuration that is public from any secrets management.
## Related
### Related decisions
We expect all our applications to use this approach.
We will plan to upgrade any of our applications that use a less-capable approach, such as hardcoding in a binary or in source code.
We will keep as-is any of our applications that use a more-capable approach, such as a licensing server.
### Related requirements
We will add devops capabilities for the files, including hooks, tests, and continuous integration.
We need to train all developer teammates on this decision.
### Related artifacts
Each area where we deploy will need its own .env file and related files.
### Related principles
Easily reversible.
## Notes
Example file `.env`:
```env
NAME=Alice Anderson
EMAIL=alice@example.com
```
Example file `.env.defaults`:
```env
NAME=Joe Doe
EMAIL=joe@example.com
```
Example file `.env.schema` with just the keys:
```env
NAME
EMAIL
```
================================================
FILE: locales/en/examples/go-programming-language/.locale-peer-id
================================================
77c69ad4fd10a2dc47f3f7a6dcbbef68
================================================
FILE: locales/en/examples/go-programming-language/index.md
================================================
# Architecture Decision Record: Go programming language
Title: Adoption of Go Programming Language
Status: Accepted
## Context
Our organization has been primarily using Java programming language for building web applications. However, we have been experiencing some challenges due to Java's verbosity and the complexity of some frameworks. Also, our team has shown interest in exploring modern programming languages for more efficient and robust development. After conducting research, we have identified Go as a potential solution to the problems we face with Java.
## Decision
We will adopt Go programming language for building web applications going forward.
## Rationale
1. **Simplicity and readability:** Go is known for its simplicity and concise syntax. This makes it easy to read and write code, reducing the complexity of our development process.
2. **High-performance and scalability:** Go is compiled into machine code that runs natively on the server. This results in faster execution times and better performance compared to interpreted languages like Java. Additionally, Go's concurrency model handles multiple requests simultaneously, making it highly scalable.
3. **Strong community support:** Go has a vibrant community of developers who have contributed to its growth over the years. This means that there are plenty of resources, libraries, and frameworks to help us get started and build robust applications.
4. **Flexibility:** Go can be used for both frontend and backend development. This means that we can leverage its advantages in both areas for our development projects.
## Implications
1. **Training:** Our developers will need to undergo training to learn the Go programming language and its nuances.
2. **Experience:** We may face some challenges as we transition from Java to Go. It may take some time for our developers to become proficient with the new language.
3. **Tooling:** We will need to adopt new tools and frameworks that are specific to Go. However, we can leverage existing infrastructure that we have in place to minimize the impact of this change.
4. **Vendor lock-in:** Go is an open-source programming language, and we will not be tied to any vendor or service provider.
## Conclusion
The adoption of Go programming language will help us improve our development process and build robust applications. We will need to invest resources in training and tools to support this transition, but we believe that the benefits of this decision outweigh the costs.
<h6>Credit: this page is generated by ChatGPT, then edited for clarity and format.</h6>
================================================
FILE: locales/en/examples/google-cloud-platform/.locale-peer-id
================================================
819cd06503cb318caf8f90fcff244b84
================================================
FILE: locales/en/examples/google-cloud-platform/index.md
================================================
# Architecture Decision Record for Google Cloud Platform
## Context
Google Cloud Platform (GCP) is a prominent cloud computing platform that offers various cloud services, including computing, storage, and networking solutions. This ADR aims to document the architectural decisions made for developing and implementing a GCP-based infrastructure for our organization.
## Decision
Our organization has decided to use Google Cloud Platform as the cloud infrastructure for our application. The primary considerations for this decision are:
- Cost-effectiveness
- Scalability
- Reliability
- Flexibility
## Selections
The following services from GCP have been selected to meet our requirements:
- Compute Engine for virtual machines and computing resources
- Cloud Storage for object storage and file hosting
- Cloud SQL for managed database service
- Firebase for app development and hosting
## Rationale
- Cost-Effectiveness: Google Cloud Platform is highly cost-effective compared to other cloud platforms, making it an attractive option for organizations with budget constraints.
- Scalability: GCP's easy-to-scale infrastructure enables handling any amount of traffic in real-time.
- Reliability: GCP's managed services offer high reliability, with automated backups and disaster recovery capabilities that ensure high availability of resources and data.
- Flexibility: The platform provides various tools and services across different domains such as AI, data analytics, and IoT, making it highly versatile.
## Consequences
Migrating to Google Cloud Platform will require training our teams on GCP services, re-architecting the application to be compatible with the selected services, and updating the infrastructure code to support GCP services. However, it is expected that once the migration is completed, we will have a highly scalable, reliable, and cost-effective infrastructure for hosting our application. Also, we will need to manage the ongoing costs of provisioning resources on GCP.
## Conclusion
Google Cloud Platform is an excellent choice for our cloud infrastructure due to its cost-effectiveness, scalability, reliability, and flexibility. By utilizing the selected services, we can provide a highly available and robust infrastructure for our application.
================================================
FILE: locales/en/examples/high-trust-teamwork/.locale-peer-id
================================================
912115918de8642859827f500f4aca23
================================================
FILE: locales/en/examples/high-trust-teamwork/index.md
================================================
# Decision Record for High Trust Teamwork
Date: [Insert Date]
Participants: [Insert Names of Participants]
Decision Reach: [Unanimous/ Majority decision/ Individual Decision]
## Decision Description
The decision to adopt High Trust Teamwork as a core value and belief in our team and organizational culture.
## Alternatives Considered
We considered alternative approaches to teamwork, including low trust or no trust teamwork, as well as other frameworks such as cognitive diversity teams, centralized decision-making teams, and agile teams.
## Benefits and Risks
The benefits of high trust teamwork include improved collaboration, better decision-making, increased motivation and engagement, higher job satisfaction and retention rates, and enhanced innovation and creativity. The risks associated with high trust teamwork include the potential for trust breaches, conflicts, and misunderstandings due to miscommunications or not adhering to the high trust principles.
## Decision Outcome
It was unanimously agreed upon to adopt high trust teamwork as the core value and belief in our team and organizational culture. We acknowledged the importance of building and maintaining trust through transparency, honesty, integrity, and respect, and recognized that this approach would help us to establish a positive and rewarding work environment.
## Action Items
To implement high trust teamwork, we will take the following steps:
1. Define high trust principles and practices and communicate these to all team members
2. Establish regular feedback mechanisms and communication channels to keep the team updated on progress, challenges, and opportunities
3. Attend training on high trust teamwork and actively participate in team-building activities
4. Encourage and recognize behaviors that demonstrate high trust principles in action
5. Develop a plan to address potential trust breaches, conflicts, or misunderstandings and have a process to handle such situations effectively
================================================
FILE: locales/en/examples/index.md
================================================
# Decision record examples
* [CSS framework](css-framework)
* [Environment variable configuration](environment-variable-configuration)
* [Metrics, monitors, alerts](metrics-monitors-alerts)
* [Microsoft Azure DevOps](microsoft-azure-devops)
* [Monorepo vs multirepo](monorepo-vs-multirepo)
* [Programming languages](programming-languages)
* [Secrets storage](secrets-storage)
* [snake_case v. camelCase for a REST API](snake-case-v-camelcase-for-a-rest-api)
* [Timestamp format](timestamp-format)
ChatGPT examples:
* [API using JSON v. gRPC](api-using-json-v-grpc)
* [Choosing a database technology](choosing-a-database-technology)
Specific programming languages:
* [Go programming language](go-programming-language)
* [Rust programming language](rust-programming-language)
* [Java programming language](java-programming-language)
* [Python programming language](python-programming-language)
Specific databases:
* [MySQL database](mysql-database)
* [PostgreSQL database](postgresql-database)
Specific container orchestration:
* [Docker Swarm container orchestration](docker-swarm-container-orchestration)
* [Kubernetes container orchestration](kubernetes-container-orchestration)
Specific web frameworks, libraries, and styles:
* [React front end JavaScript library](react-front-end-javascript-library)
* [Ruby on Rails framework](ruby-on-rails-framework)
* [Svelte front end JavaScript library](svelte-front-end-javascript-library)
* [SvelteKit framework](sveltekit-framework)
* [Tailwind CSS](tailwind-css)
* [Vue front end JavaScript library](vue-front-end-javascript-library)
================================================
FILE: locales/en/examples/java-programming-language/.locale-peer-id
================================================
984e1e50927d81ec862d5899cd3cb077
================================================
FILE: locales/en/examples/java-programming-language/index.md
================================================
# Architecture Decision Record: Java programming language
Title: Choosing Java Programming Language for the Project
Decision: After evaluating multiple programming languages, we have decided to use Java for our project.
### Background
We intended to build a web-based application that could run on multiple operating systems. Our project required a language that could provide strong security features, handle concurrency, support large code bases, and be versatile enough to meet our future growth requirements. We evaluated several languages, considering their strengths and limitations, before deciding on Java.
### Considerations
1. **Security:** Java provides excellent security features through its well-defined security policies and access control. It also incorporates features like bytecode verification, which helps prevent malicious software from running on a system.
2. **Concurrency:** Java has built-in support for multithreading, which allows applications to perform several tasks simultaneously. This feature makes Java an excellent choice for developing large, complex applications with multiple features and functionalities.
3. **Large codebases:** Java supports object-oriented programming, which makes it a suitable choice for developing large codebases. Its modular nature and use of encapsulation and abstraction patterns further add to the software development process's ease.
4. **Versatility:** Java is versatile and provides the ability to use a wide range of libraries and frameworks, making it an excellent choice for both web-based and enterprise-level applications.
### Decision Outcome
We have decided to use the Java programming language for our project, considering its security features, concurrency support, ability to handle large codebases, and versatility. This decision aligns with our project requirements, and we believe that choosing Java will ensure its success.
### Consequences
1. We will need developers who have experience with Java and can use it proficiently.
2. Any code written in the language must be compatible with the Java Virtual Machine (JVM).
3. Incorporating new features, functionalities, or frameworks may present some challenges.
4. Large, complex projects in Java may require more time and resources to develop.
<h6>Credit: this page is generated by ChatGPT, then edited for clarity and format.</h6>
================================================
FILE: locales/en/examples/kubernetes-container-orchestration/.locale-peer-id
================================================
cb3edecf9181c9c28bbbbc5d323ec733
================================================
FILE: locales/en/examples/kubernetes-container-orchestration/index.md
================================================
# Architecture Decision Record: Kubernetes container orchestration
## Problem Statement
We need to select a container orchestration platform for our growing cloud-native application portfolio. Our current legacy platform deployment is too slow, and not agile enough to keep up with our growing needs. We’re looking for a system that will allow us to scale our services in the most efficient way possible without compromising on agility or ease of use.
## Considered Alternatives
1. Docker Swarm
2. Kubernetes
3. Apache Mesos
## Decision Made
After conducting a thorough analysis of each container orchestration platform, we have decided to adopt Kubernetes as the best option for our enterprise needs. Our reasons for choosing Kubernetes are as follows:
1. **Scalability:** Kubernetes’s unique design is perfect for scaling applications, and as our requirements for scalability evolve over time, Kubernetes has the built-in ability to meet these changes without any issues.
2. **Decentralized Architecture:** Kubernetes’ master-worker topology ensures a decentralized architecture which ensures that there is no single point of failure.
3. **Community Support:** Kubernetes has the largest and most active open-source community, which means it has a large number of contributors, developers, and vendors making it easier for us to get help and find resources.
4. **Ecosystem Support:** Kubernetes has a growing ecosystem with a variety of third-party tools, integrations with container registries, CI/CD pipelines, data storage, and more.
Therefore, we have decided to adopt Kubernetes as our container orchestration platform for the present and the immediate future.
<h6>Credit: this page is generated by ChatGPT, then edited for clarity and format.</h6>
================================================
FILE: locales/en/examples/metrics-monitors-alerts/.locale-peer-id
================================================
d97e71af7770a8cfefb718b2ffd28062
================================================
FILE: locales/en/examples/metrics-monitors-alerts/index.md
================================================
# Metrics, monitors, alerts
Contents:
* [Summary](#summary)
* [Issue](#issue)
* [Decision](#decision)
* [Status](#status)
* [Details](#details)
* [Assumptions](#assumptions)
* [Constraints](#constraints)
* [Positions](#positions)
* [Argument](#argument)
* [Implications](#implications)
* [Related](#related)
* [Related decisions](#related-decisions)
* [Related requirements](#related-requirements)
* [Related artifacts](#related-artifacts)
* [Related principles](#related-principles)
* [Notes](#notes)
* [Freeform text messages vs structured event messages](#freeform-text-messages-vs-structured-event-messages)
* [Graylog is easier](#graylog-is-easier)
* [Prometheus take some tuning](#prometheus-take-some-tuning)
* [AWS services are mixed](#aws-services-are-mixed)
* [Kafka](#kafka)
* [Loki](#loki)
* [Prometheus + alertmanager + Rollbar + Graylog + Grafana](#prometheus-alertmanager-rollbar-graylog-grafana)
* [Thanos](#thanos)
* [Prometheus HA](#prometheus-ha)
* [Datadog + PagerDuty + Threat Stack](#datadog-pagerduty-threat-stack)
* [Zabbix](#zabbix)
* [Outlyer](#outlyer)
* [Nagios + Nagiosgraph](#nagios-nagiosgraph)
* [Prometheus + Grafana + AlertManager](#prometheus-grafana-alertmanager)
* [DataDog + Sentry + PagerDuty.](#datadog-sentry-pagerduty)
* [Sensu + Graphite + ELK](#sensu-graphite-elk)
* [Prometheus + Alertmanager](#prometheus-alertmanager)
* [Sensu + Grafana + Graylog + Kibana + NewRelic.](#sensu-grafana-graylog-kibana-newrelic)
* [Prometheus + Circonus](#prometheus-circonus)
* [icinga2 + VictorOps + NewRelic + Sentry + Slack](#icinga2-victorops-newrelic-sentry-slack)
* [AppDynamics + Papertrail + PagerDuty + Healthchecks.io + Stackdriver](#appdynamics-papertrail-pagerduty-healthchecks-io-stackdriver)
* [icinga2 + elasticsearch](#icinga2-elasticsearch)
* [DataDog + New Relic + ELK + EFK + Sentry + Alertmanager + VictorOps](#datadog-new-relic-elk-efk-sentry-alertmanager-victorops)
* [Wavefront + Scalyr + PagerDuty + Stackstorm + Slack](#wavefront-scalyr-pagerduty-stackstorm-slack)
* [Telegraf + Prometheus + InfluxDB + Grafana](#telegraf-prometheus-influxdb-grafana)
* [Sematext + Logagent + Experience](#sematext-logagent-experience)
* [Azure Monitor/Analytics + OpsGenie](#azure-monitor-analytics-opsgenie)
* [Prometheus + Alertmanager + Grafana + Splunk + PagerDuty](#prometheus-alertmanager-grafana-splunk-pagerduty)
* [Telegraf + Prometheus + Grafana + Alertmanager](#telegraf-prometheus-grafana-alertmanager)
* [Prometheus + Grafana + Cloudwatch + sentry + kibana + elasticsearch](#prometheus-grafana-cloudwatch-sentry-kibana-elasticsearch)
* [PagerDuty + Monitis](#pagerduty-monitis)
* [Prometheus + Grafana + Bosun](#prometheus-grafana-bosun)
* [Azure Monitor/Analytics/Insights/Dashboards](#azure-monitor-analytics-insights-dashboards)
* [Grafana + Monitis + OpsGenie + Slack](#grafana-monitis-opsgenie-slack)
* [Checkly + AppOptics + Cloudwatch + Heroku + Pagerduty + Papertrail](#checkly-appoptics-cloudwatch-heroku-pagerduty-papertrail)
* [Instana + Logz.io + slack](#instana-logz-io-slack)
* [SignalFX + Splunk + PagerDuty + Slack](#signalfx-splunk-pagerduty-slack)
* [ELK + Prometheus + Grafana](#elk-prometheus-grafana)
* [Datadog + Prometheus + Grafana](#datadog-prometheus-grafana)
* [Nagios + ELK](#nagios-elk)
* [Datadog vs. Site24x7 + StatusCake + PagerDuty + SumoLogic + Slack](#datadog-vs-site24x7-statuscake-pagerduty-sumologic-slack)
* [Prometheus + AlertManager + Grafana + Stackdriver](#prometheus-alertmanager-grafana-stackdriver)
* [Zabbix](#zabbix)
## Summary
### Issue
We want to use metrics, monitors, and alerts, because we want to know how well our applications are working, and to know when there's a problem.
### Decision
WIP.
### Status
Gathering information. We are starting with the plausible ends of the spectrum: the most-recommended older free tool (Nagios) and the most-recommended newer paid tool (New Relic).
## Details
### Assumptions
We want to create web apps that are modern, fast, reliable, responsive, etc.
We want to buy rather than build.
### Constraints
We want tooling that works well with our devops pipeline and with our deployment clouds.
### Positions
We are researching positions now.
* AlertManager
* AppDynamics
* AppOptics
* Azure Monitor/Analytics/Insights/Dashboards
* Bosun
* Checkly
* Circonus
* Cloudwatch
* EFK
* ELK
* Grafana
* Grafana
* Graphite
* Graylog
* Healthchecks.io
* Heroku
* icinga2
* InfluxDB
* Instana
* Kafka
* Logagent
* Logz.io
* Loki
* Monitis
* Nagios
* Nagios
* Nagiosgraph
* NewRelic
* OpsGenie
* Outlyer
* PagerDuty
* Pagerduty
* PagerDuty
* Papertrail
* Prometheus
* Rollbar
* Scalyr
* Sematext Metrics, Logs, Experience, Tracing
* Sensu
* SignalFX
* Slack
* Splunk
* Stackdriver
* Stackstorm
* Telegraf
* Telegraf
* Thanos
* VictorOps
* Wavefront
* Zabbix
### Argument
So far, Nagios and New Relic are the ends of the spectrum. Nagios is the oldest, simplest, free, viable tool. New Relic is the newest-featured, most-complete, paid, viable tool. We will start with evaluations of these. As needed, we will migrate into the spectrum.
So far, Zabbix has the best recommendations, and also offers the most complete capabilities.
So far, ELK has the best open-source build-over-buy popularity.
So far, Prometheus + Graphana have the best popularity.
### Implications
TODO.
## Related
### Related decisions
The choices will affect testability, telemetry, and likely other systems such as for customer service, site reliability engineering, etc.
### Related requirements
TODO.
### Related artifacts
TODO.
### Related principles
Easily reversible.
Need for speed.
## Notes
A pretty good open source stack is:
* Prometheus for metrics and alerting based on metrics
* Grafana to display metrics
* Elasticsearch/Logstash/Kibana (ELK) for logs and structured events
* Pushover for mobile notifications
### Freeform text messages vs structured event messages
Freeform text messages: for example, the kind of random stuff you would find in /var/log/messages, and something generated intentionally by the application. The messages are useful for identifying other things that are happening on the box like out of memory or hardware errors, but have a lot of junk.
Structured event messages: generated by the application, with a fixed or dynamic set of attributes, e.g. a HTTP request log, an accounting log, a user login.
Generally speaking, it's nice to log details about every request in a way that you can drill down based on attributes. So adding e.g. a userid or sessionid to everything lets you trace. Explicit tracing is also good, of course. Using ELK for this is kind of a poor man's https://www.honeycomb.io/
### Graylog is easier
Graylog is easier to spin up from my experience.
### Prometheus take some tuning
I am generally happy with Prometheus for metrics. The alerting takes some tuning, but is pretty good. It depends on your application. I think it's best to alert on end-user visible conditions, not underlying causes. For example, page load time is good, number of requests per second is not. Though zero requests per second indicates that something is wrong.
The advantage of a service is that they offer additional intelligence out of the box. I generally like Datadog. The services can be frighteningly expensive if you have a lot of data, and sometimes have pricing models which are not cloud friendly, e.g. charging per instance, when instances are dynamic. There is also a difference between services where every request is from a paid user and ones that are advertising related, so only some small percentage of the requests make you money. You can end up with a lot of data and not that much budget.
I work on some services that get 1B requests a day, so it makes sense to host our own monitoring and logging. If your volumes are lower, then hosted services are easier.
### AWS services are mixed
My experience with AWS services has been mixed. Their Elasticsearch service has been flaky, so we run our own instances for that. CloudWatch metrics are expensive, so we generally only use them for "infrastructure" level metrics rather than the application, i.e. health-related metrics where AWS can know better what's going on than software running on the instance. CloudWatch Logs can be slow to update and don't have that much metadata. Running ELK helps with that. If I really want real time data, then using Kafka as the transport for logs is better. That's pretty well supported by Logstash. Managing a Kafka cluster is not for the faint hearted, though, there is a lot of exposed plumbing.
### Kafka
Comment: Kafka can be super tricky at times, or Kafka can be rock solid and you almost forget about it being there tying everything together.
Comment: Kafka has been solid, but it was a surprising amount of work getting it going. I think of it like a relational database but you are only working at the "physical" layer, e.g. tablespaces, files and partitions. There were some times early on where the management utilities were lacking, and we had to write programs to e.g. reset a consumer group. http://howfuckedismydatabase.com/nosql/
Comment: We use Kafka as a "buffer" for log messages and a place where we can do real time stream processing on data that is coming from multiple servers. If we get a DDOS attack, then we need a way of analyzing data across multiple instances. If we are logging directly from the servers to ELK, the load can blow up the Elasticsearch cluster.
Comment: Kafka is good for us because if we get a DDOS attack, then we need a way of analyzing data across multiple instances. If we are logging directly from the servers to ELK, the load can blow up the Elasticsearch cluster.
Comment: Kafka does less work and is more efficient, so it can handle the load better. And we queue the Kafka work and retry. And having Kafka be overloaded doesn't affect users who are trying to do interactive work with Kibana, the way it would if Elasticsearch is struggling.
Comment: Stream processing is mostly looking for abuse, e.g. too much traffic from a single IP across the whole cluster, and then share the block across the whole cluster.
Comment: The logstash-output-kafka plugin is quite unreliable at the moment though. I've been bit by several of the issues on its GitHub issues page, that never seem to get fixed. I want to move away from using it, to sending directly from our apps to Kafka.
Comment: We are now sending structured events directly from the app to Kafka. The main motivation was touching the log data fewer times and avoiding reading and writing the disk multiple times. In high volume systems, logging can take more work than the app itself. I am thinking about making journald send logs directly as well, from a C program.
### Loki
Keep a close eye on Loki. It’s not ready yet but when it is I’d expect it to be a better fit in this stack. Loki is a log aggregator created by grafana labs, it uses similar a scraping and tag syntax as Prometheus.
### Prometheus + alertmanager + Rollbar + Graylog + Grafana
Prometheus + alertmanager for metrics. <3 Prometheus.
Rollbar/Graylog for logging/error reporting (there's some overlap here; a small service probably doesn't need both).
Currently, alerts just go to one of a few Slack channels that interested parties have notifications turned on for. If we were more serious about on-call they would go to PagerDuty/VictorOps/etc.
Grafana for graphs and dashboarding. Also eagerly looking forward to seeing if their upcoming logging facilities will obviate Graylog.
### Thanos
We use Thanos as a front-end for our HA setup. It knows how to de-duplicate HA pairs.
We're currently keeping 6 months of local Prometheus data. This works reasonably well for us. But I'm just in the middle of rolling out bucket storage to our Thanos setup for long-term data storage. In theory, GCS storage will be about 30% cheaper than the GCE standard persistent disk we use right now.
We don't backup Prometheus data right now. The data just isn't really important to us beyond having enough for alerting. Our overall fleet deployment changes so much year to year that historical data older than a few months just isn't that interesting. It might be interesting to have a few core stats year-over-year, I may setup a core-stats set of recording rules and store those with Federation or just let Thanos take care of it.
EDIT: Minor disclaimer, I'm a Prometheus developer.
### Prometheus HA
HA in Prometheus is done by duplication you run multiple poppers there’s ways to poll multiple and deduplicate the data
The scaling is by deciding network and having different Prometheus poll different parts of the network
Longterm storage isn’t proms strong point but is offloaded to something like influxes or timescaledb (which technically does the HA checkmark as well) article I read on it https://blog.timescale.com/prometheus-ha-postgresql-8de68d19b6f5?gi=7df160f10e07
Haven’t tried the longterm stuff yet as I’m still only experimenting and using it for short term graphs while librenms monitors my network for longterm
### Datadog + PagerDuty + Threat Stack
We use Datadog (w/ PagerDuty) and Threat Stack and couldn't be happier. My only gripe with DD is the relatively high cost of metric storage
gitextract_2a7geaq3/
├── CITATION.cff
├── CODE_OF_CONDUCT.md
├── LICENSE.md
├── README.md
└── locales/
├── cy/
│ ├── .locale-peer-id
│ ├── nogfennau/
│ │ ├── .locale-peer-id
│ │ ├── awgrymiadau-ar-gyfer-ysgrifennu-adrs-da/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── beth-yw-cofnod-penderfyniad-pensaernïaeth/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── canllawiau-i-gyflawni-penderfyniadau-cynaliadwy/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── confensiynau-enw-ffeil/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cwestiynau-gwaith-tîm-ar-gyfer-adrau/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cyngor-gwaith-tîm-ar-gyfer-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── meini-prawf-cynaliadwyedd-penderfynu/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── proses-cofnodion-penderfynol-pensaernïol-aws/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── sut-i-ddechrau-defnyddio-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── sut-i-ddechrau-defnyddio-adrs-gyda-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── sut-i-ddechrau-defnyddio-adrs-gydag-offer/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── templedi/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── templed-cofnod-penderfyniad-ar-gyfer-achos-busnes/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-ar-gyfer-patrwm-alecsandraidd/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-jeff-tyree-and-art-akerman/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── templed-cofnod-penderfyniad-gan-planguage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── templed-cofnod-penderfyniad-y-prosiect-madr/
│ ├── .locale-peer-id
│ └── index.md
├── en/
│ ├── .locale-peer-id
│ ├── documents/
│ │ ├── .locale-peer-id
│ │ ├── aws-adr-process/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── decision-sustainability-criteria/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── file-name-conventions-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── fitness-functions-for-decisions-as-code/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── guidelines-to-achieve-sustainable-decisions/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-tools/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── suggestions-for-writing-good-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── teamwork-advice-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── teamwork-questions-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── what-is-an-architecture-decision-record/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── examples/
│ │ ├── .locale-peer-id
│ │ ├── 4-day-work-week/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── agile-software-development/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── amazon-web-services/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── api-using-json-v-grpc/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── authentication-authorization-options/
│ │ │ └── index.md
│ │ ├── browser-automation-framework-for-e2e-testing-playwright-vs-selenium/
│ │ │ └── index.md
│ │ ├── chart-library-toolkit-for-data-visualization-using-typescript-and-json/
│ │ │ └── index.md
│ │ ├── choosing-a-database-technology/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── continuous-integration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── css-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── docker-swarm-container-orchestration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── environment-variable-configuration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── go-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── google-cloud-platform/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── high-trust-teamwork/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── index.md
│ │ ├── java-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── kubernetes-container-orchestration/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── metrics-monitors-alerts/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── microsoft-azure-cloud-infrastructure/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── microsoft-azure-devops/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── monorepo-vs-multirepo/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── mysql-database/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── postgresql-database/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── programming-code-editors/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── programming-languages/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── python-django-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── python-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── react-front-end-javascript-library/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── ruby-on-rails-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── rust-programming-language/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── secrets-storage/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── snake-case-v-camelcase-for-a-rest-api/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── svelte-components/
│ │ │ └── index.md
│ │ ├── svelte-front-end-javascript-library/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── sveltekit-framework/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── tailwind-css/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── timestamp-format/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── vue-front-end-javascript-library/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── web-application-framework-batteries-included-full-stack-for-a-startup-product/
│ │ │ └── index.md
│ │ └── work-from-home/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── templates/
│ ├── .locale-peer-id
│ ├── decision-record-template-by-arc42/
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-by-edgex/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-by-gareth-morgan/
│ │ ├── README.md
│ │ └── index.md
│ ├── decision-record-template-by-gig-cymru-nhs-wales/
│ │ └── index.md
│ ├── decision-record-template-by-jeff-tyree-and-art-akerman/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE-WIP.md
│ │ └── index.md
│ ├── decision-record-template-by-michael-nygard/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-for-alexandrian-pattern/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── decision-record-template-for-business-case/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── decision-record-template-of-the-madr-project/
│ │ ├── .locale-peer-id
│ │ ├── LICENSE.md
│ │ └── index.md
│ ├── decision-record-template-using-planguage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── index.md
├── es/
│ ├── .locale-peer-id
│ ├── documentos/
│ │ ├── .locale-peer-id
│ │ ├── consejo-de-trabajo-en-equipo-para-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── convenciones-de-nombre-de-archivo/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── criterios-de-sostenibilidad-de-decisión/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cómo-comenzar-a-usar-adr-con-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cómo-comenzar-a-usar-adr-con-herramientas/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── cómo-comenzar-a-usar-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── directrices-para-lograr-decisiones-sostenibles/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── proceso-de-registros-de-decisiones-arquitectónicas-de-aws/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── qué-es-un-registro-de-decisión-de-arquitectura/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── sugerencias-para-escribir-buenos-adr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── plantillas/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── plantilla-de-registro-de-decisión-de-edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-de-jeff-tyree-y-art-akerman/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-de-michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-del-proyecto-madr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-para-caso-de-negocio/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── plantilla-de-registro-de-decisión-para-el-patrón-alejandrino/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── plantilla-de-registro-de-decisión-usando-planguage/
│ ├── .locale-directory-name-en.txt
│ ├── .locale-peer-id
│ └── index.md
├── fr/
│ ├── .locale-peer-id
│ ├── documents/
│ │ ├── .locale-peer-id
│ │ ├── comment-commencer-à-utiliser-les-adr/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── comment-commencer-à-utiliser-les-adr-avec-des-outils/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── comment-commencer-à-utiliser-les-adr-avec-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── conseils-de-travail-déquipe-pour-les-adr/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── conventions-de-noms-de-fichiers/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── critères-de-durabilité-de-décision/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── lignes-directrices-pour-atteindre-des-décisions-durables/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── processus-des-dossiers-de-décision-architecturale-aws/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── quest-ce-quun-dossier-de-décision-darchitecture/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── suggestions-pour-écrire-de-bonnes-adr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── modèles/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── modèle-denregistrement-de-décision par jeff-tyree-et-art-akerman/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision pour-lanalyse-de-rentabilisation/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision utilisant-plangage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision-du-projet-madr/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision-par michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── modèle-denregistrement-de-décision-par-edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── modèle-denregistrement-de-décision-pour-le modèle-alexandrin/
│ ├── .locale-peer-id
│ └── index.md
├── index.md
├── ja/
│ ├── .locale-peer-id
│ ├── テンプレート/
│ │ ├── .locale-peer-id
│ │ ├── EdgeX Foundryによる意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── Jeff TyreeとArt Akermanによる意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── Michael Nygard による意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── Planguageを使用した意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── index.md
│ │ ├── madrプロジェクトの意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── アレクサンドリアパターンの意思決定記録テンプレート/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── ビジネスケース用意思決定記録テンプレート/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── ドキュメント/
│ │ ├── .locale-peer-id
│ │ ├── aws-adr-process/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── decision-sustainability-criteria/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── file-name-conventions-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── guidelines-to-achieve-sustainable-decisions/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-git/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── how-to-start-using-adrs-with-tools/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── suggestions-for-writing-good-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── teamwork-advice-for-adrs/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── what-is-an-architecture-decision-record/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── 翻訳注.txt
├── ko/
│ ├── .locale-peer-id
│ ├── 서류/
│ │ ├── .locale-peer-id
│ │ ├── adr-사용을-시작하는-방법/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── adr을-위한-팀워크-조언/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── aws-아키텍처-결정-기록-프로세스/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── git에서-adr-사용을-시작하는-방법/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 도구를-사용하여-adr-사용을-시작하는-방법/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 아키텍처-결정-기록이란-무엇입니까/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 의사결정-지속가능성-기준/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 좋은-adr-작성을-위한-제안/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ ├── 지속-가능한-결정을-달성하기-위한-지침/
│ │ │ ├── .locale-peer-id
│ │ │ └── index.md
│ │ └── 파일-이름-규칙/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── 템플릿/
│ ├── .locale-peer-id
│ ├── index.md
│ ├── madr 프로젝트의 결정 기록 템플릿/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 결정 기록 템플릿별 edgex/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 비즈니스 사례에 대한 의사결정 기록 템플릿/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 알렉산드리아 패턴에 대한 결정 기록 템플릿/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 의사 결정 기록 템플릿-by-michael-nygard/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── 의사결정 기록 템플릿 사용 p언어/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── 의사결정 기록 템플릿-by-jeff-tyree-and-art-akerman/
│ ├── .locale-peer-id
│ └── index.md
└── tr/
├── .locale-peer-id
├── documents/
│ ├── .locale-peer-id
│ ├── aws-adr-process/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── decision-sustainability-criteria/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── file-name-conventions-for-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── guidelines-to-achieve-sustainable-decisions/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── how-to-start-using-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── how-to-start-using-adrs-with-git/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── how-to-start-using-adrs-with-tools/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── suggestions-for-writing-good-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── teamwork-advice-for-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── teamwork-questions-for-adrs/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ └── what-is-an-architecture-decision-record/
│ ├── .locale-peer-id
│ └── index.md
├── examples/
│ ├── .locale-peer-id
│ ├── 4-day-work-week/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── agile-software-development/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── amazon-web-services/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── api-using-json-v-grpc/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── authentication-authorization-options/
│ │ └── index.md
│ ├── browser-automation-framework-for-e2e-testing-playwright-vs-selenium/
│ │ └── index.md
│ ├── chart-library-toolkit-for-data-visualization-using-typescript-and-json/
│ │ └── index.md
│ ├── choosing-a-database-technology/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── continuous-integration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── css-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── docker-swarm-container-orchestration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── environment-variable-configuration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── go-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── google-cloud-platform/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── high-trust-teamwork/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── index.md
│ ├── java-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── kubernetes-container-orchestration/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── metrics-monitors-alerts/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── microsoft-azure-cloud-infrastructure/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── microsoft-azure-devops/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── monorepo-vs-multirepo/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── mysql-database/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── postgresql-database/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── programming-code-editors/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── programming-languages/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── python-django-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── python-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── react-front-end-javascript-library/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── ruby-on-rails-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── rust-programming-language/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── secrets-storage/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── snake-case-v-camelcase-for-a-rest-api/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── svelte-components/
│ │ └── index.md
│ ├── svelte-front-end-javascript-library/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── sveltekit-framework/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── tailwind-css/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── timestamp-format/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── vue-front-end-javascript-library/
│ │ ├── .locale-peer-id
│ │ └── index.md
│ ├── web-application-framework-batteries-included-full-stack-for-a-startup-product/
│ │ └── index.md
│ └── work-from-home/
│ ├── .locale-peer-id
│ └── index.md
└── templates/
├── .locale-peer-id
├── decision-record-template-by-arc42/
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-by-edgex/
│ ├── .locale-peer-id
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-by-gareth-morgan/
│ ├── README.md
│ └── index.md
├── decision-record-template-by-gig-cymru-nhs-wales/
│ └── index.md
├── decision-record-template-by-jeff-tyree-and-art-akerman/
│ ├── .locale-peer-id
│ ├── LICENSE-WIP.md
│ └── index.md
├── decision-record-template-by-michael-nygard/
│ ├── .locale-peer-id
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-for-alexandrian-pattern/
│ ├── .locale-peer-id
│ └── index.md
├── decision-record-template-for-business-case/
│ ├── .locale-peer-id
│ └── index.md
├── decision-record-template-of-the-madr-project/
│ ├── .locale-peer-id
│ ├── LICENSE.md
│ └── index.md
├── decision-record-template-using-planguage/
│ ├── .locale-peer-id
│ └── index.md
└── index.md
Condensed preview — 453 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (784K chars).
[
{
"path": "CITATION.cff",
"chars": 707,
"preview": "cff-version: 1.2.0\ntitle: Architecture decision record (ADR)\nmessage: >-\n If you use this work and you want to cite it,"
},
{
"path": "CODE_OF_CONDUCT.md",
"chars": 5490,
"preview": "\n# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nWe as members, contributors, and leaders pledge to make particip"
},
{
"path": "LICENSE.md",
"chars": 410,
"preview": "# License\n\nFor the work that I've personally done, such as writing the README.md file, the license is CC BY-NC-SA.\n\nhttp"
},
{
"path": "README.md",
"chars": 29947,
"preview": "<!--\n browser: architecture-decision-record\n tracker: 2bd6622ec3beeeddd8ff55cf0ccf2efc\n version: 3.2.0\n updated: 202"
},
{
"path": "locales/cy/.locale-peer-id",
"chars": 33,
"preview": "0b59cb46e5817b414866ebe33f4d7bcf\n"
},
{
"path": "locales/cy/nogfennau/.locale-peer-id",
"chars": 33,
"preview": "abc7c72d426bc75e40b25a44ae37ce73\n"
},
{
"path": "locales/cy/nogfennau/awgrymiadau-ar-gyfer-ysgrifennu-adrs-da/.locale-peer-id",
"chars": 33,
"preview": "dc1a294e76821d6d3b086a2b17988427\n"
},
{
"path": "locales/cy/nogfennau/awgrymiadau-ar-gyfer-ysgrifennu-adrs-da/index.md",
"chars": 1842,
"preview": "## Awgrymiadau ar gyfer ysgrifennu ADRs da\n\nNodweddion ADR da:\n\n * Rhesymeg: Esboniwch y rhesymau dros wneud yr hysbys"
},
{
"path": "locales/cy/nogfennau/beth-yw-cofnod-penderfyniad-pensaernïaeth/.locale-peer-id",
"chars": 33,
"preview": "020ff535ed1a3347a265209291e756b6\n"
},
{
"path": "locales/cy/nogfennau/beth-yw-cofnod-penderfyniad-pensaernïaeth/index.md",
"chars": 1007,
"preview": "## Beth yw cofnod penderfyniad pensaernïaeth?\n\nMae Cofnod Penderfyniad Pensaernïaeth ** ** (ADR) yn ddogfen sy'n cyfleu "
},
{
"path": "locales/cy/nogfennau/canllawiau-i-gyflawni-penderfyniadau-cynaliadwy/.locale-peer-id",
"chars": 33,
"preview": "934d1c42a693fe004cd8bf8f5ecb97e6\n"
},
{
"path": "locales/cy/nogfennau/canllawiau-i-gyflawni-penderfyniadau-cynaliadwy/index.md",
"chars": 1749,
"preview": "# Canllawiau i gyflawni penderfyniadau cynaliadwy\n\n<https://www.infoq.com/articles/sustainable-architectural-design-deci"
},
{
"path": "locales/cy/nogfennau/confensiynau-enw-ffeil/.locale-peer-id",
"chars": 33,
"preview": "89116b5647aa1e53186f3c44b5a284a0\n"
},
{
"path": "locales/cy/nogfennau/confensiynau-enw-ffeil/index.md",
"chars": 762,
"preview": "# Confensiynau Enw Ffeil\n\nOs dewiswch greu eich ADRs gan ddefnyddio ffeiliau testun nodweddiadol, yna efallai yr hoffech"
},
{
"path": "locales/cy/nogfennau/cwestiynau-gwaith-tîm-ar-gyfer-adrau/.locale-peer-id",
"chars": 33,
"preview": "60057747e4547af35fd888021e41f332\n"
},
{
"path": "locales/cy/nogfennau/cwestiynau-gwaith-tîm-ar-gyfer-adrau/index.md",
"chars": 4740,
"preview": "## Cwestiynau gwaith tîm ar gyfer ADRau\n\n### Pwy all greu ADR?\n\nYstyriwch feysydd fel pobl benodol, neu rolau penodol, n"
},
{
"path": "locales/cy/nogfennau/cyngor-gwaith-tîm-ar-gyfer-adrs/.locale-peer-id",
"chars": 33,
"preview": "875a7715e592ceb45eac5e155ee16318\n"
},
{
"path": "locales/cy/nogfennau/cyngor-gwaith-tîm-ar-gyfer-adrs/index.md",
"chars": 1822,
"preview": "# Cyngor gwaith tîm ar gyfer ADRs\n\nOs ydych chi'n ystyried defnyddio cofnodion penderfyniadau gyda'ch tîm, yna dyma ychy"
},
{
"path": "locales/cy/nogfennau/meini-prawf-cynaliadwyedd-penderfynu/.locale-peer-id",
"chars": 33,
"preview": "71d59ed566ae148b8bf42331a84754ac\n"
},
{
"path": "locales/cy/nogfennau/meini-prawf-cynaliadwyedd-penderfynu/index.md",
"chars": 1823,
"preview": "# Meini Prawf Cynaliadwyedd Penderfynu\n\n<https://www.infoq.com/articles/sustainable-architectural-design-decisions/>\n\nEr"
},
{
"path": "locales/cy/nogfennau/proses-cofnodion-penderfynol-pensaernïol-aws/.locale-peer-id",
"chars": 33,
"preview": "7d4adf16004ca42546dee49922ae4ccf\n"
},
{
"path": "locales/cy/nogfennau/proses-cofnodion-penderfynol-pensaernïol-aws/index.md",
"chars": 5952,
"preview": "# Proses Cofnodion Penderfynol Pensaernïol AWS\n\nhttps://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-d"
},
{
"path": "locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs/.locale-peer-id",
"chars": 33,
"preview": "8196518140224596af99a46d512feba3\n"
},
{
"path": "locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs/index.md",
"chars": 1924,
"preview": "# Sut i ddechrau defnyddio ADRs\n\nI ddechrau defnyddio ADRs, siaradwch â'ch cyd -chwaraewyr am yr ardaloedd hyn.\n\nAdnabod"
},
{
"path": "locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gyda-git/.locale-peer-id",
"chars": 33,
"preview": "d6fb3c7d91f95003163e694e74058e9d\n"
},
{
"path": "locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gyda-git/index.md",
"chars": 520,
"preview": "# Sut i ddechrau defnyddio ADRs gyda git\n\nOs ydych chi'n hoffi defnyddio rheolaeth fersiwn GIT, yna dyma sut rydyn ni'n "
},
{
"path": "locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gydag-offer/.locale-peer-id",
"chars": 33,
"preview": "1a5a03dd6f20cea9f78fb4655a9a7f87\n"
},
{
"path": "locales/cy/nogfennau/sut-i-ddechrau-defnyddio-adrs-gydag-offer/index.md",
"chars": 616,
"preview": "## Sut i ddechrau defnyddio ADRs gydag offer\n\nGallwch chi ddechrau defnyddio ADRs gydag offer unrhyw ffordd rydych chi e"
},
{
"path": "locales/cy/templedi/.locale-peer-id",
"chars": 33,
"preview": "70f1f9b3530831bc891a6e9b9b0d27de\n"
},
{
"path": "locales/cy/templedi/index.md",
"chars": 758,
"preview": "# Templedi cofnodion penderfyniadau\n\n* [Templed cofnod penderfyniad gan Jeff Tyree ac Art Akerman](templed-cofnod-pender"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-achos-busnes/.locale-peer-id",
"chars": 33,
"preview": "f6d1fb662640a00f4c66c586233dead9\n"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-achos-busnes/index.md",
"chars": 2925,
"preview": "# Templed cofnod penderfyniad ar gyfer achos busnes\n\nMae’r templed ADR hwn yn pwysleisio creu achos busnes ar gyfer pend"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-patrwm-alecsandraidd/.locale-peer-id",
"chars": 33,
"preview": "f33e4eb0409f956de201b791749dc9aa\n"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-ar-gyfer-patrwm-alecsandraidd/index.md",
"chars": 799,
"preview": "# Templed cofnod penderfyniad ar gyfer patrwm Alecsandraidd\n\n## Rhagymadrodd\n\n* Prologue (Crynodeb)\n* Trafodaeth (Cyd-de"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-edgex/.locale-peer-id",
"chars": 33,
"preview": "01939db0c341e9092c344d904065da12\n"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-edgex/index.md",
"chars": 2437,
"preview": "# Templed Cofnod Penderfyniad Pensaernïaeth (ADR) <!-- Rhoi teitl ADR --> yn ei le\n\nMae hwn yn dempled ar gyfer EdgeX Fo"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-jeff-tyree-and-art-akerman/.locale-peer-id",
"chars": 33,
"preview": "f4ca0a94124a91279e1929ea23ab864d\n"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-jeff-tyree-and-art-akerman/index.md",
"chars": 4637,
"preview": "# Templed cofnod penderfyniad gan Jeff Tyree ac Art Akerman\n\nDyma'r templed disgrifiad penderfyniad pensaernïaeth a gyho"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-michael-nygard/.locale-peer-id",
"chars": 33,
"preview": "b1e90e6556c1c8f1e2eb3ac22c8c5077\n"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-michael-nygard/index.md",
"chars": 733,
"preview": "# Templed cofnod penderfyniad gan Michael Nygard\n\nDyma'r templed yn [Dogfennu penderfyniadau pensaernïaeth - Michael Nyg"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-planguage/.locale-peer-id",
"chars": 33,
"preview": "bb37e19df57d398b0704d6bd30ee6e6d\n"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-gan-planguage/index.md",
"chars": 1079,
"preview": "# Templed cofnod penderfyniad gan ddefnyddio Planguage\n\nGweler https://www.iaria.org/conferences2012/filesICCGI12/Tutori"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-y-prosiect-madr/.locale-peer-id",
"chars": 33,
"preview": "0a9f88e5cda952db0a82d071f585d090\n"
},
{
"path": "locales/cy/templedi/templed-cofnod-penderfyniad-y-prosiect-madr/index.md",
"chars": 2307,
"preview": "# [teitl byr y broblem a'r datrysiad a ddatryswyd]\n\n* Statws: [ arfaethedig | gwrthodwyd | derbyn | anghymeradwy | … | w"
},
{
"path": "locales/en/.locale-peer-id",
"chars": 33,
"preview": "0b59cb46e5817b414866ebe33f4d7bcf\n"
},
{
"path": "locales/en/documents/.locale-peer-id",
"chars": 33,
"preview": "abc7c72d426bc75e40b25a44ae37ce73\n"
},
{
"path": "locales/en/documents/aws-adr-process/.locale-peer-id",
"chars": 33,
"preview": "7d4adf16004ca42546dee49922ae4ccf\n"
},
{
"path": "locales/en/documents/aws-adr-process/index.md",
"chars": 5652,
"preview": "# AWS Architectural Decision Records Process\n\nhttps://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-dec"
},
{
"path": "locales/en/documents/decision-sustainability-criteria/.locale-peer-id",
"chars": 33,
"preview": "71d59ed566ae148b8bf42331a84754ac\n"
},
{
"path": "locales/en/documents/decision-sustainability-criteria/index.md",
"chars": 1740,
"preview": "# Decision Sustainability Criteria\n\n<https://www.infoq.com/articles/sustainable-architectural-design-decisions/>\n\nTo def"
},
{
"path": "locales/en/documents/file-name-conventions-for-adrs/.locale-peer-id",
"chars": 33,
"preview": "89116b5647aa1e53186f3c44b5a284a0\n"
},
{
"path": "locales/en/documents/file-name-conventions-for-adrs/index.md",
"chars": 670,
"preview": "# File name conventions\n\nIf you choose to create your ADRs using typical text files, then you may want to come up with y"
},
{
"path": "locales/en/documents/fitness-functions-for-decisions-as-code/.locale-peer-id",
"chars": 33,
"preview": "23615a056e17c4097ee648d8c7352733\n"
},
{
"path": "locales/en/documents/fitness-functions-for-decisions-as-code/index.md",
"chars": 1962,
"preview": "# Fitness functions for decisions as code\n\nFitness functions are objective automated checks, written with programming co"
},
{
"path": "locales/en/documents/guidelines-to-achieve-sustainable-decisions/.locale-peer-id",
"chars": 33,
"preview": "934d1c42a693fe004cd8bf8f5ecb97e6\n"
},
{
"path": "locales/en/documents/guidelines-to-achieve-sustainable-decisions/index.md",
"chars": 1642,
"preview": "# Guidelines to Achieve Sustainable Decisions\n\n<https://www.infoq.com/articles/sustainable-architectural-design-decision"
},
{
"path": "locales/en/documents/how-to-start-using-adrs/.locale-peer-id",
"chars": 33,
"preview": "8196518140224596af99a46d512feba3\n"
},
{
"path": "locales/en/documents/how-to-start-using-adrs/index.md",
"chars": 1775,
"preview": "# How to start using ADRs\n\nTo start using ADRs, talk with your teammates about these areas.\n\nDecision identification:\n\n "
},
{
"path": "locales/en/documents/how-to-start-using-adrs-with-git/.locale-peer-id",
"chars": 33,
"preview": "d6fb3c7d91f95003163e694e74058e9d\n"
},
{
"path": "locales/en/documents/how-to-start-using-adrs-with-git/index.md",
"chars": 443,
"preview": "# How to start using ADRs with git\n\nIf you like using git version control, then here is how we like to start using ADRs "
},
{
"path": "locales/en/documents/how-to-start-using-adrs-with-tools/.locale-peer-id",
"chars": 33,
"preview": "1a5a03dd6f20cea9f78fb4655a9a7f87\n"
},
{
"path": "locales/en/documents/how-to-start-using-adrs-with-tools/index.md",
"chars": 517,
"preview": "## How to start using ADRs with tools\n\nYou can start using ADRs with tools any way you want.\n\nFor example:\n\n * If you l"
},
{
"path": "locales/en/documents/suggestions-for-writing-good-adrs/.locale-peer-id",
"chars": 33,
"preview": "dc1a294e76821d6d3b086a2b17988427\n"
},
{
"path": "locales/en/documents/suggestions-for-writing-good-adrs/index.md",
"chars": 1754,
"preview": "## Suggestions for writing good ADRs\n\nCharacteristics of a good ADR:\n\n* Rationale: Explain the reasons for doing the par"
},
{
"path": "locales/en/documents/teamwork-advice-for-adrs/.locale-peer-id",
"chars": 33,
"preview": "875a7715e592ceb45eac5e155ee16318\n"
},
{
"path": "locales/en/documents/teamwork-advice-for-adrs/index.md",
"chars": 1611,
"preview": "# Teamwork advice for ADRs\n\nIf you're considering using decision records with your team, then here's some advice that we"
},
{
"path": "locales/en/documents/teamwork-questions-for-adrs/.locale-peer-id",
"chars": 33,
"preview": "60057747e4547af35fd888021e41f332\n"
},
{
"path": "locales/en/documents/teamwork-questions-for-adrs/index.md",
"chars": 4500,
"preview": "\n### Who can create an ADR?\n\nConsider areas such as specific people, or specific roles, or specific teams, or specific d"
},
{
"path": "locales/en/documents/what-is-an-architecture-decision-record/.locale-peer-id",
"chars": 33,
"preview": "020ff535ed1a3347a265209291e756b6\n"
},
{
"path": "locales/en/documents/what-is-an-architecture-decision-record/index.md",
"chars": 1018,
"preview": "## What is an architecture decision record?\n\nAn **architecture decision record** (ADR) is a document that captures an im"
},
{
"path": "locales/en/examples/.locale-peer-id",
"chars": 1,
"preview": "\n"
},
{
"path": "locales/en/examples/4-day-work-week/.locale-peer-id",
"chars": 33,
"preview": "fb15d0e84550135e2e7a280693ba5848\n"
},
{
"path": "locales/en/examples/4-day-work-week/index.md",
"chars": 2820,
"preview": "# Decision record for 4-day work-week\n\nTitle: Implementation of 4-Day Work-week\n\n## Context and Problem Statement\n\nOur o"
},
{
"path": "locales/en/examples/agile-software-development/.locale-peer-id",
"chars": 33,
"preview": "a4bc089ce8e95a6dce0fb0845081674a\n"
},
{
"path": "locales/en/examples/agile-software-development/index.md",
"chars": 1796,
"preview": "# Decision record for agile software development\n\nTitle Introduction of Agile Software Development\n\nDate: [Insert Date]\n"
},
{
"path": "locales/en/examples/amazon-web-services/.locale-peer-id",
"chars": 33,
"preview": "c4beaa505311198b2b00341fe42c948f\n"
},
{
"path": "locales/en/examples/amazon-web-services/index.md",
"chars": 2459,
"preview": "# Architecture Decision Record for Amazon Web Services\n\nTitle: Adopting Amazon Web Services for Cloud Infrastructure\n\n##"
},
{
"path": "locales/en/examples/api-using-json-v-grpc/.locale-peer-id",
"chars": 33,
"preview": "7c91a4cc326aecb7f1a62a6d41b8b4fd\n"
},
{
"path": "locales/en/examples/api-using-json-v-grpc/index.md",
"chars": 2017,
"preview": "# Architecture Decision Record: API using JSON v. gRPC\n\n## Status\n\nAccepted\n\n## Context\n\nWe are designing an API for a n"
},
{
"path": "locales/en/examples/authentication-authorization-options/index.md",
"chars": 8207,
"preview": "# Architecture Decision Record: authentication authorization options\n\n<!--\n\nChatGPT prompt:\n\nExplain web application aut"
},
{
"path": "locales/en/examples/browser-automation-framework-for-e2e-testing-playwright-vs-selenium/index.md",
"chars": 10151,
"preview": "## Architecture decision record: browser automation framework for E2E testing (Playwright vs Selenium)\n\n### 1. **Context"
},
{
"path": "locales/en/examples/chart-library-toolkit-for-data-visualization-using-typescript-and-json/index.md",
"chars": 12616,
"preview": "# Architecture Decision Record: chart library toolkit for data visualization using TypeScript and JSON\n\n<!--\n\nChatGPT pr"
},
{
"path": "locales/en/examples/choosing-a-database-technology/.locale-peer-id",
"chars": 33,
"preview": "ee24129d8750e5ceebb9b4ff7b3cfb1a\n"
},
{
"path": "locales/en/examples/choosing-a-database-technology/index.md",
"chars": 2826,
"preview": "# Architecture Decision Record: Choosing a Database Technology\n\n## Status\n\nAccepted\n\n## Context\n\nWe are designing a new "
},
{
"path": "locales/en/examples/continuous-integration/.locale-peer-id",
"chars": 33,
"preview": "45cdbd2e37d773b7e0592a142fd5de30\n"
},
{
"path": "locales/en/examples/continuous-integration/index.md",
"chars": 1543,
"preview": "# Decision Record for continuous integration\n\nTitle: Decision to Implement Continuous Integration\n\n## Context\n\nThe compa"
},
{
"path": "locales/en/examples/css-framework/.locale-peer-id",
"chars": 33,
"preview": "694d2d4235299f058990c1cc470af15e\n"
},
{
"path": "locales/en/examples/css-framework/index.md",
"chars": 4696,
"preview": "# Architecture Decision Record: CSS framework\n\nContents:\n\n- [Summary](#summary)\n - [Issue](#issue)\n - [Decision](#deci"
},
{
"path": "locales/en/examples/docker-swarm-container-orchestration/.locale-peer-id",
"chars": 33,
"preview": "3d27355877340537b28efb2bae3a6907\n"
},
{
"path": "locales/en/examples/docker-swarm-container-orchestration/index.md",
"chars": 3183,
"preview": "# Architecture Decision Record: Docker Swarm Container Orchestration\n\nDecision Number: 001\n\nDecision Maker: [Your name o"
},
{
"path": "locales/en/examples/environment-variable-configuration/.locale-peer-id",
"chars": 33,
"preview": "46b0910941ab1812cda52b34baca5798\n"
},
{
"path": "locales/en/examples/environment-variable-configuration/index.md",
"chars": 3767,
"preview": "# Environment variable configuration\n\nContents:\n\n* [Summary](#summary)\n * [Issue](#issue)\n * [Decision](#decision)\n *"
},
{
"path": "locales/en/examples/go-programming-language/.locale-peer-id",
"chars": 33,
"preview": "77c69ad4fd10a2dc47f3f7a6dcbbef68\n"
},
{
"path": "locales/en/examples/go-programming-language/index.md",
"chars": 2611,
"preview": "# Architecture Decision Record: Go programming language\n\nTitle: Adoption of Go Programming Language\n\nStatus: Accepted\n\n#"
},
{
"path": "locales/en/examples/google-cloud-platform/.locale-peer-id",
"chars": 33,
"preview": "819cd06503cb318caf8f90fcff244b84\n"
},
{
"path": "locales/en/examples/google-cloud-platform/index.md",
"chars": 2335,
"preview": "# Architecture Decision Record for Google Cloud Platform\n\n## Context\n\nGoogle Cloud Platform (GCP) is a prominent cloud c"
},
{
"path": "locales/en/examples/high-trust-teamwork/.locale-peer-id",
"chars": 33,
"preview": "912115918de8642859827f500f4aca23\n"
},
{
"path": "locales/en/examples/high-trust-teamwork/index.md",
"chars": 1995,
"preview": "# Decision Record for High Trust Teamwork\n\nDate: [Insert Date]\n\nParticipants: [Insert Names of Participants]\n\nDecision R"
},
{
"path": "locales/en/examples/index.md",
"chars": 1611,
"preview": "# Decision record examples\n\n* [CSS framework](css-framework)\n\n* [Environment variable configuration](environment-variabl"
},
{
"path": "locales/en/examples/java-programming-language/.locale-peer-id",
"chars": 33,
"preview": "984e1e50927d81ec862d5899cd3cb077\n"
},
{
"path": "locales/en/examples/java-programming-language/index.md",
"chars": 2384,
"preview": "# Architecture Decision Record: Java programming language\n\nTitle: Choosing Java Programming Language for the Project\n\nDe"
},
{
"path": "locales/en/examples/kubernetes-container-orchestration/.locale-peer-id",
"chars": 33,
"preview": "cb3edecf9181c9c28bbbbc5d323ec733\n"
},
{
"path": "locales/en/examples/kubernetes-container-orchestration/index.md",
"chars": 1774,
"preview": "# Architecture Decision Record: Kubernetes container orchestration\n\n## Problem Statement \n\nWe need to select a container"
},
{
"path": "locales/en/examples/metrics-monitors-alerts/.locale-peer-id",
"chars": 33,
"preview": "d97e71af7770a8cfefb718b2ffd28062\n"
},
{
"path": "locales/en/examples/metrics-monitors-alerts/index.md",
"chars": 24984,
"preview": "# Metrics, monitors, alerts\n\nContents:\n\n* [Summary](#summary)\n * [Issue](#issue)\n * [Decision](#decision)\n * [Status]"
},
{
"path": "locales/en/examples/microsoft-azure-cloud-infrastructure/.locale-peer-id",
"chars": 33,
"preview": "4dce71df0db78d050f86e1a2cc4cb9d1\n"
},
{
"path": "locales/en/examples/microsoft-azure-cloud-infrastructure/index.md",
"chars": 2501,
"preview": "# Architecture Decision Record: Microsoft Azure cloud infrastructure\" \n\nDecision Title: Adopting Microsoft Azure as the "
},
{
"path": "locales/en/examples/microsoft-azure-devops/.locale-peer-id",
"chars": 33,
"preview": "e1e84e31e7b1463322b083fd2983fe1a\n"
},
{
"path": "locales/en/examples/microsoft-azure-devops/index.md",
"chars": 8863,
"preview": "# Microsoft Azure DevOps\n\nContents:\n\n* [Summary](#summary)\n * [Issue](#issue)\n * [Decision](#decision)\n * [Status](#s"
},
{
"path": "locales/en/examples/monorepo-vs-multirepo/.locale-peer-id",
"chars": 33,
"preview": "b52cc745a00570dede6cd309dd35d7ac\n"
},
{
"path": "locales/en/examples/monorepo-vs-multirepo/index.md",
"chars": 4301,
"preview": "# Monorepo vs multirepo\n\nContents:\n\n* [Summary](#summary)\n * [Issue](#issue)\n * [Decision](#decision)\n * [Status](#st"
},
{
"path": "locales/en/examples/mysql-database/.locale-peer-id",
"chars": 33,
"preview": "4f4246ee263e7d47d7533ed048c2c7ef\n"
},
{
"path": "locales/en/examples/mysql-database/index.md",
"chars": 3343,
"preview": "# Architecture Decision Record: MySQL database\n\nTitle: Choosing MySQL as Database Management System for Project X\n\n## Co"
},
{
"path": "locales/en/examples/postgresql-database/.locale-peer-id",
"chars": 33,
"preview": "4ea514a9c996ef7af8eca37ec2b96d69\n"
},
{
"path": "locales/en/examples/postgresql-database/index.md",
"chars": 2272,
"preview": "# Architecture Decision Record: PostgreSQL database\n\nTitle: Use of PostgreSQL Database\n\n## Context\n\nOur organization is "
},
{
"path": "locales/en/examples/programming-code-editors/.locale-peer-id",
"chars": 33,
"preview": "8aec4ce83bd164e7b2945f37c052a6d1\n"
},
{
"path": "locales/en/examples/programming-code-editors/index.md",
"chars": 3606,
"preview": "# Architecture Decision Record: Programming Code Editors\n\n## Context\n\nProgramming code editors are an essential tool for"
},
{
"path": "locales/en/examples/programming-languages/.locale-peer-id",
"chars": 33,
"preview": "1984c4f82b0b1364c6a3fae147697337\n"
},
{
"path": "locales/en/examples/programming-languages/index.md",
"chars": 6971,
"preview": "# Programming languages\n\nContents:\n\n* [Summary](#summary)\n * [Issue](#issue)\n * [Decision](#decision)\n * [Status](#st"
},
{
"path": "locales/en/examples/python-django-framework/.locale-peer-id",
"chars": 33,
"preview": "b8f60539494aed8b17e1b8969ae2f10b\n"
},
{
"path": "locales/en/examples/python-django-framework/index.md",
"chars": 2933,
"preview": "# Architecture Decision Record for Python Django Framework\n\nDecision Date: 2021-07-15\n\nStatus: Accepted\n\n## Context\n\nOur"
},
{
"path": "locales/en/examples/python-programming-language/.locale-peer-id",
"chars": 33,
"preview": "42fd8a00f5f37e2f2a9c4a3f2fd61356\n"
},
{
"path": "locales/en/examples/python-programming-language/index.md",
"chars": 3052,
"preview": "# Architecture Decision Record: Python programming language\n\n## Context\n\nWe need to decide on whether to use Python as a"
},
{
"path": "locales/en/examples/react-front-end-javascript-library/.locale-peer-id",
"chars": 33,
"preview": "9eadfd943b9e3d2404a28e8ad14d3076\n"
},
{
"path": "locales/en/examples/react-front-end-javascript-library/index.md",
"chars": 2577,
"preview": "# Architecture Decision Record: React Front-End JavaScript Library\n\n## Context\n\nWe need to choose a front-end JavaScript"
},
{
"path": "locales/en/examples/ruby-on-rails-framework/.locale-peer-id",
"chars": 33,
"preview": "b107a749a966e10cc337420370e34063\n"
},
{
"path": "locales/en/examples/ruby-on-rails-framework/index.md",
"chars": 2370,
"preview": "# Architecture Decision Record: Ruby on Rails Framework\n\n## Context\n\n- The organization is developing a web application "
},
{
"path": "locales/en/examples/rust-programming-language/.locale-peer-id",
"chars": 33,
"preview": "d21b58847a2e92716ef2f68b44156564\n"
},
{
"path": "locales/en/examples/rust-programming-language/index.md",
"chars": 3694,
"preview": "# Architecture Decision Record: Rust programming language\n\nDecision Number: AR-001\n\nDecision Title: Adoption of Rust pro"
},
{
"path": "locales/en/examples/secrets-storage/.locale-peer-id",
"chars": 33,
"preview": "8123c8089cda027baecab9c034e947c6\n"
},
{
"path": "locales/en/examples/secrets-storage/index.md",
"chars": 13663,
"preview": "# Secrets storage\n\nContents:\n\n* [Summary](#summary)\n * [Issue](#issue)\n * [Decision](#decision)\n * [Status](#status)\n"
},
{
"path": "locales/en/examples/snake-case-v-camelcase-for-a-rest-api/.locale-peer-id",
"chars": 33,
"preview": "56bcc02899f133bd74208e58e020ad3a\n"
},
{
"path": "locales/en/examples/snake-case-v-camelcase-for-a-rest-api/index.md",
"chars": 2686,
"preview": "# Architecture Decision Record: snake_case v. camelCase for a REST API?\n\nDecision: snake_case naming convention will be "
},
{
"path": "locales/en/examples/svelte-components/index.md",
"chars": 7212,
"preview": "# Architecture Decision Record (ADR) for Svelte Components\n\n<!--\n\nPrompt:\n\nArchitecture decision record for Svelte compo"
},
{
"path": "locales/en/examples/svelte-front-end-javascript-library/.locale-peer-id",
"chars": 33,
"preview": "bdca98499db7dd51eeb5add1ca5ec974\n"
},
{
"path": "locales/en/examples/svelte-front-end-javascript-library/index.md",
"chars": 3141,
"preview": "# Architecture Decision Record: Svelte Front-end JavaScript Library\n\nStatus: Accepted\n\n## Context\n\nWe are developing a w"
},
{
"path": "locales/en/examples/sveltekit-framework/.locale-peer-id",
"chars": 33,
"preview": "0bc6820a0b59edb03d91948dcfcd6cd0\n"
},
{
"path": "locales/en/examples/sveltekit-framework/index.md",
"chars": 2346,
"preview": "# Architecture Decision Record: SvelteKit framework\n\n* Date: [Current Date]\n\n* Status: [proposed, approved, rejected, de"
},
{
"path": "locales/en/examples/tailwind-css/.locale-peer-id",
"chars": 33,
"preview": "496e7846025a0701822dc65ca71180a5\n"
},
{
"path": "locales/en/examples/tailwind-css/index.md",
"chars": 2940,
"preview": "# Architecture Decision Record: Tailwind CSS\n\nDecision: Use Tailwind CSS as the CSS framework to style a user interface."
},
{
"path": "locales/en/examples/timestamp-format/.locale-peer-id",
"chars": 33,
"preview": "9374af360cb954bffd75c8518a93b25d\n"
},
{
"path": "locales/en/examples/timestamp-format/index.md",
"chars": 4407,
"preview": "# Timestamp format\n\nContents:\n\n* [Summary](#summary)\n * [Issue](#issue)\n * [Decision](#decision)\n * [Status](#status)"
},
{
"path": "locales/en/examples/vue-front-end-javascript-library/.locale-peer-id",
"chars": 33,
"preview": "b43f7e984abc2ba89f2738c3e63203aa\n"
},
{
"path": "locales/en/examples/vue-front-end-javascript-library/index.md",
"chars": 2283,
"preview": "# Architecture Decision Record: Vue front-end JavaScript library\n\nDate: [Date of decision]\n\nStatus: [Draft/Final/Postpon"
},
{
"path": "locales/en/examples/web-application-framework-batteries-included-full-stack-for-a-startup-product/index.md",
"chars": 10985,
"preview": "# Architecture Decision Record: web application framework, batteries included, full stack, for a startup product\n\n<!-- \n"
},
{
"path": "locales/en/examples/work-from-home/.locale-peer-id",
"chars": 33,
"preview": "0a53cbdf9f479da77ad7e0a6128275a9\n"
},
{
"path": "locales/en/examples/work-from-home/index.md",
"chars": 2565,
"preview": "# Decision record for work from home\n\nTitle: Employees can work from home\n\nDecision Maker: Management Team\n\nDecision Dat"
},
{
"path": "locales/en/templates/.locale-peer-id",
"chars": 33,
"preview": "70f1f9b3530831bc891a6e9b9b0d27de\n"
},
{
"path": "locales/en/templates/decision-record-template-by-arc42/LICENSE.md",
"chars": 146,
"preview": "# LICENSE\n\nSource: <https://arc42.org/overview>\n\nLicense: <https://arc42.org/license>\n\nLicense: <https://creativecommons"
},
{
"path": "locales/en/templates/decision-record-template-by-arc42/index.md",
"chars": 22528,
"preview": "# Decision record template by arc42\n\n<https://arc42.org/overview>\n\n## 1. Introduction and Goals\n\nShort description of th"
},
{
"path": "locales/en/templates/decision-record-template-by-edgex/.locale-peer-id",
"chars": 33,
"preview": "01939db0c341e9092c344d904065da12\n"
},
{
"path": "locales/en/templates/decision-record-template-by-edgex/LICENSE.md",
"chars": 143,
"preview": "# LICENSE\n\nSource: https://docs.edgexfoundry.org/2.3/design/adr/template/\n\nLicense: https://github.com/edgexfoundry/edge"
},
{
"path": "locales/en/templates/decision-record-template-by-edgex/index.md",
"chars": 2206,
"preview": "# Architecture Decision Record (ADR) template <!-- Replace with ADR title -->\n\nThis is a template for EdgeX Foundry ADR."
},
{
"path": "locales/en/templates/decision-record-template-by-gareth-morgan/README.md",
"chars": 8,
"preview": "index.md"
},
{
"path": "locales/en/templates/decision-record-template-by-gareth-morgan/index.md",
"chars": 4928,
"preview": "# [000] Title\n*Allocate each ADR a number for easy reference and cataloging* \\\n*NOTE: All italicised text provides hints"
},
{
"path": "locales/en/templates/decision-record-template-by-gig-cymru-nhs-wales/index.md",
"chars": 4954,
"preview": "# {Your Title Here}\n\n!!! info\n\n **Status**: { Proposed | Under Review | Accepted | Rejected | Superseded | Deprecate"
},
{
"path": "locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/.locale-peer-id",
"chars": 33,
"preview": "f4ca0a94124a91279e1929ea23ab864d\n"
},
{
"path": "locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/LICENSE-WIP.md",
"chars": 1183,
"preview": "# LICENSE WIP\n\n```email\nFrom:Joel Parker Henderson <joel@joelparkerhenderson.com>\nTo:Help@computer.org\nSubject:License q"
},
{
"path": "locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/index.md",
"chars": 4266,
"preview": "# Decision record template by Jeff Tyree and Art Akerman\n\nThis is the architecture decision description template publish"
},
{
"path": "locales/en/templates/decision-record-template-by-michael-nygard/.locale-peer-id",
"chars": 33,
"preview": "b1e90e6556c1c8f1e2eb3ac22c8c5077\n"
},
{
"path": "locales/en/templates/decision-record-template-by-michael-nygard/LICENSE.md",
"chars": 426,
"preview": "# LICENSE\n\nThis content comes from this URL:\n\nhttps://cognitect.com/blog/2011/11/15/documenting-architecture-decisions\n\n"
},
{
"path": "locales/en/templates/decision-record-template-by-michael-nygard/index.md",
"chars": 689,
"preview": "# Decision record template by Michael Nygard\n\nThis is the template in [Documenting architecture decisions - Michael Nyga"
},
{
"path": "locales/en/templates/decision-record-template-for-alexandrian-pattern/.locale-peer-id",
"chars": 33,
"preview": "f33e4eb0409f956de201b791749dc9aa\n"
},
{
"path": "locales/en/templates/decision-record-template-for-alexandrian-pattern/index.md",
"chars": 750,
"preview": "# Decision record template for Alexandrian pattern\n\n## Introduction\n\n* Prologue (Summary)\n* Discussion (Context)\n* Solut"
},
{
"path": "locales/en/templates/decision-record-template-for-business-case/.locale-peer-id",
"chars": 33,
"preview": "f6d1fb662640a00f4c66c586233dead9\n"
},
{
"path": "locales/en/templates/decision-record-template-for-business-case/index.md",
"chars": 2713,
"preview": "# Decision record template for business case\n\nThis ADR template emphasizes creating a business case for a decision, incl"
},
{
"path": "locales/en/templates/decision-record-template-of-the-madr-project/.locale-peer-id",
"chars": 33,
"preview": "0a9f88e5cda952db0a82d071f585d090\n"
},
{
"path": "locales/en/templates/decision-record-template-of-the-madr-project/LICENSE.md",
"chars": 129,
"preview": "# LICENSE\n\nSource: https://github.com/adr/madr/\n\nLicense: https://github.com/adr/madr/blob/develop/LICENSE\n\nCode: MIT OR"
},
{
"path": "locales/en/templates/decision-record-template-of-the-madr-project/index.md",
"chars": 2204,
"preview": "# [short title of solved problem and solution]\n\n* Status: [proposed | rejected | accepted | deprecated | … | superseded "
},
{
"path": "locales/en/templates/decision-record-template-using-planguage/.locale-peer-id",
"chars": 33,
"preview": "bb37e19df57d398b0704d6bd30ee6e6d\n"
},
{
"path": "locales/en/templates/decision-record-template-using-planguage/index.md",
"chars": 1070,
"preview": "# Decision record template using Planguage\n\nSee https://www.iaria.org/conferences2012/filesICCGI12/Tutorial%20Specifying"
},
{
"path": "locales/en/templates/index.md",
"chars": 991,
"preview": "# Decision record templates\n\n* [Decision record template by Jeff Tyree and Art Akerman](decision-record-template-by-jeff"
},
{
"path": "locales/es/.locale-peer-id",
"chars": 33,
"preview": "0b59cb46e5817b414866ebe33f4d7bcf\n"
},
{
"path": "locales/es/documentos/.locale-peer-id",
"chars": 33,
"preview": "abc7c72d426bc75e40b25a44ae37ce73\n"
},
{
"path": "locales/es/documentos/consejo-de-trabajo-en-equipo-para-adrs/.locale-peer-id",
"chars": 33,
"preview": "875a7715e592ceb45eac5e155ee16318\n"
},
{
"path": "locales/es/documentos/consejo-de-trabajo-en-equipo-para-adrs/index.md",
"chars": 1878,
"preview": "# Consejo de trabajo en equipo para ADRS\n\nSi está considerando usar registros de decisión con su equipo, aquí hay alguno"
},
{
"path": "locales/es/documentos/convenciones-de-nombre-de-archivo/.locale-peer-id",
"chars": 33,
"preview": "89116b5647aa1e53186f3c44b5a284a0\n"
},
{
"path": "locales/es/documentos/convenciones-de-nombre-de-archivo/index.md",
"chars": 781,
"preview": "# Convenciones de nombre de archivo\n\nSi elige crear sus ADR usando archivos de texto típicos, es posible que desee crear"
},
{
"path": "locales/es/documentos/criterios-de-sostenibilidad-de-decisión/.locale-peer-id",
"chars": 33,
"preview": "71d59ed566ae148b8bf42331a84754ac\n"
},
{
"path": "locales/es/documentos/criterios-de-sostenibilidad-de-decisión/index.md",
"chars": 1969,
"preview": "# Criterios de sostenibilidad de decisión\n\n<https://www.infoq.com/articles/sustainable-architectural-design-decisions/>\n"
},
{
"path": "locales/es/documentos/cómo-comenzar-a-usar-adr-con-git/.locale-peer-id",
"chars": 33,
"preview": "d6fb3c7d91f95003163e694e74058e9d\n"
},
{
"path": "locales/es/documentos/cómo-comenzar-a-usar-adr-con-git/index.md",
"chars": 490,
"preview": "# Cómo comenzar a usar ADR con Git\n\nSi le gusta usar el control de versiones Git, entonces así es cómo nos gusta comenza"
},
{
"path": "locales/es/documentos/cómo-comenzar-a-usar-adr-con-herramientas/.locale-peer-id",
"chars": 33,
"preview": "1a5a03dd6f20cea9f78fb4655a9a7f87\n"
},
{
"path": "locales/es/documentos/cómo-comenzar-a-usar-adr-con-herramientas/index.md",
"chars": 574,
"preview": "## Cómo comenzar a usar ADR con herramientas\n\nPuede comenzar a usar ADR con herramientas de la manera que desee.\n\nPor ej"
},
{
"path": "locales/es/documentos/cómo-comenzar-a-usar-adrs/.locale-peer-id",
"chars": 33,
"preview": "8196518140224596af99a46d512feba3\n"
},
{
"path": "locales/es/documentos/cómo-comenzar-a-usar-adrs/index.md",
"chars": 2077,
"preview": "# Cómo comenzar a usar ADRS\n\nPara comenzar a usar ADR, hable con sus compañeros de equipo sobre estas áreas.\n\nIdentifica"
},
{
"path": "locales/es/documentos/directrices-para-lograr-decisiones-sostenibles/.locale-peer-id",
"chars": 33,
"preview": "934d1c42a693fe004cd8bf8f5ecb97e6\n"
},
{
"path": "locales/es/documentos/directrices-para-lograr-decisiones-sostenibles/index.md",
"chars": 1829,
"preview": "# Directrices para lograr decisiones sostenibles\n\n<https://www.infoq.com/articles/sustainable-architectural-design-decis"
},
{
"path": "locales/es/documentos/proceso-de-registros-de-decisiones-arquitectónicas-de-aws/.locale-peer-id",
"chars": 33,
"preview": "7d4adf16004ca42546dee49922ae4ccf\n"
},
{
"path": "locales/es/documentos/proceso-de-registros-de-decisiones-arquitectónicas-de-aws/index.md",
"chars": 6256,
"preview": "# Proceso de registros de decisiones arquitectónicas de AWS\n\nhttps://docs.aws.amazon.com/prescriptive-guidance/latest/ar"
},
{
"path": "locales/es/documentos/qué-es-un-registro-de-decisión-de-arquitectura/.locale-peer-id",
"chars": 33,
"preview": "020ff535ed1a3347a265209291e756b6\n"
},
{
"path": "locales/es/documentos/qué-es-un-registro-de-decisión-de-arquitectura/index.md",
"chars": 1147,
"preview": "## ¿Qué es un registro de decisión de arquitectura?\n\nUn registro de decisión de arquitectura ** ** (ADR) es un documento"
},
{
"path": "locales/es/documentos/sugerencias-para-escribir-buenos-adr/.locale-peer-id",
"chars": 33,
"preview": "dc1a294e76821d6d3b086a2b17988427\n"
},
{
"path": "locales/es/documentos/sugerencias-para-escribir-buenos-adr/index.md",
"chars": 1962,
"preview": "## Sugerencias para escribir buenos ADR\n\nCaracterísticas de un buen ADR:\n\n * Justificación: explique las razones para "
},
{
"path": "locales/es/plantillas/.locale-peer-id",
"chars": 33,
"preview": "70f1f9b3530831bc891a6e9b9b0d27de\n"
},
{
"path": "locales/es/plantillas/index.md",
"chars": 741,
"preview": "# Plantilla de registro de decisiones\n\n* [Plantilla de registro de decisión de Jeff Tyree y Art Akerman](plantilla-de-re"
},
{
"path": "locales/es/plantillas/plantilla-de-registro-de-decisión-de-edgex/.locale-peer-id",
"chars": 33,
"preview": "01939db0c341e9092c344d904065da12\n"
},
{
"path": "locales/es/plantillas/plantilla-de-registro-de-decisión-de-edgex/index.md",
"chars": 5358,
"preview": "# Plantilla de registro de decisión de arquitectura (ADR) <!-- Reemplazar con el título de ADR -->\n\nEsta es una plantill"
},
{
"path": "locales/es/plantillas/plantilla-de-registro-de-decisión-de-jeff-tyree-y-art-akerman/.locale-peer-id",
"chars": 33,
"preview": "f4ca0a94124a91279e1929ea23ab864d\n"
},
{
"path": "locales/es/plantillas/plantilla-de-registro-de-decisión-de-jeff-tyree-y-art-akerman/index.md",
"chars": 4675,
"preview": "# Plantilla de registro de decisiones de Jeff Tyree y Art Akerman\n\nEsta es la plantilla de descripción de decisiones arq"
}
]
// ... and 253 more files (download for full content)
About this extraction
This page contains the full source code of the joelparkerhenderson/architecture-decision-record GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 453 files (709.8 KB), approximately 204.6k tokens. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.