ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ (ADR)
ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರಗಳನ್ನು ದಾಖಲಿಸಲು ಟೆಂಪ್ಲೇಟುಗಳು, ಉದಾಹರಣೆಗಳು ಮತ್ತು ಮಾರ್ಗದರ್ಶನ.
ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ (ADR) ಎಂದರೆ ಮಾಡಿದ ಒಂದು ಪ್ರಮುಖ ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರವನ್ನು ಅದರ ಸಂದರ್ಭ ಮತ್ತು ಪರಿಣಾಮಗಳೊಂದಿಗೆ ಸೆರೆಹಿಡಿಯುವ ದಾಖಲೆ.
ಅನುವಾದಗಳು: العربية, বাংলা, Cymraeg, Dansk, Deutsch, English, Lietuvių, Gaeilge, Lëtzebuergesch, తెలుగు, தமிழ், मराठी, Hausa, ગુજરાતી, Euskara, भोजपुरी, Basa Jawa, فارسی, ਪੰਜਾਬੀ, Bahasa Melayu, ಕನ್ನಡ, Malti, Latviešu, Slovenščina, Slovenčina, Hrvatski, Български, Čeština, Magyar, Ελληνικά, Română, Polski, Español, Eesti, Suomi, Français, עברית, हिन्दी, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Nederlands, Português, Русский, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文
- ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ ಎಂದರೇನು?
ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ (ADR) ಎಂದರೆ ಮಾಡಿದ ಒಂದು ಪ್ರಮುಖ ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರವನ್ನು ಅದರ ಸಂದರ್ಭ ಮತ್ತು ಪರಿಣಾಮಗಳೊಂದಿಗೆ ಸೆರೆಹಿಡಿಯುವ ದಾಖಲೆ.
- ADR ಬಳಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ
ADR ಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲು, ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳೊಂದಿಗೆ ಈ ವಿಷಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಿ.
- ಉತ್ತಮ ADR ಗಳನ್ನು ಬರೆಯಲು ಸಲಹೆಗಳು
ತಾರ್ಕಿಕತೆ: ನಿರ್ದಿಷ್ಟ AD ಯನ್ನು ಮಾಡುವುದರ ಕಾರಣಗಳನ್ನು ವಿವರಿಸಿ. ಇದರಲ್ಲಿ ಸಂದರ್ಭ (ಕೆಳಗೆ ನೋಡಿ), ವಿವಿಧ ಸಂಭಾವ್ಯ ಆಯ್ಕೆಗಳ ಸಾಧಕ-ಬಾಧಕಗಳು, ವೈಶಿಷ್ಟ್ಯ ಹೋಲಿಕೆಗಳು, ವೆಚ್ಚ/ಲಾಭ ಚರ್ಚೆಗಳು ಮತ್ತು…
- ADR ಉದಾಹರಣೆ ಟೆಂಪ್ಲೇಟುಗಳು
ಮೈಕೆಲ್ ನೈಗಾರ್ಡ್ ಅವರ ADR ಟೆಂಪ್ಲೇಟು (ಸರಳ ಮತ್ತು ಜನಪ್ರಿಯ)
- ADR ಗಾಗಿ ತಂಡಕಾರ್ಯ ಸಲಹೆ
ನಿಮ್ಮ ತಂಡದೊಂದಿಗೆ ನಿರ್ಧಾರ ದಾಖಲೆಗಳನ್ನು ಬಳಸುವುದನ್ನು ನೀವು ಪರಿಗಣಿಸುತ್ತಿದ್ದರೆ, ಅನೇಕ ತಂಡಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೂಲಕ ನಾವು ಕಲಿತ ಕೆಲವು ಸಲಹೆಗಳು ಇಲ್ಲಿವೆ.
- ಕೋಡ್ ರೂಪದ ನಿರ್ಧಾರಗಳಿಗೆ ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು
ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು (fitness functions) ಎಂದರೆ ನಿರ್ಧಾರಗಳನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲಾಗುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ, ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಕೋಡ್ನಿಂದ ಬರೆದ ವಸ್ತುನಿಷ್ಠ ಸ್ವಯಂಚಾಲಿತ ಪರಿಶೀಲನೆಗಳು.
ಯಾವುದೇ ನಿರ್ಣಾಯಕ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಬಳಸುವ ಮೊದಲು ಈ ಸಂಪನ್ಮೂಲಗಳ ಬಗ್ಗೆ ನಿಮ್ಮದೇ ಆದ ಸೂಕ್ತ ಪರಿಶ್ರಮ ನಡೆಸಿ.
ವಿಷಯಗಳು:
- ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ ಎಂದರೇನು?
- ADR ಬಳಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ
- ಸಾಧನಗಳೊಂದಿಗೆ ADR ಬಳಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ
- git ನೊಂದಿಗೆ ADR ಬಳಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ
- ADR ಗಾಗಿ Claude Code ಕೌಶಲ್ಯಗಳು
- ADR ಗಾಗಿ ಕಡತ ಹೆಸರು ಸಂಪ್ರದಾಯಗಳು
- ಉತ್ತಮ ADR ಗಳನ್ನು ಬರೆಯಲು ಸಲಹೆಗಳು
- ADR ಉದಾಹರಣೆ ಟೆಂಪ್ಲೇಟುಗಳು
- ADR ಗಾಗಿ ತಂಡಕಾರ್ಯ ಸಲಹೆ
- ADR ಗಾಗಿ ತಂಡಕಾರ್ಯ ಪ್ರಶ್ನೆಗಳು
- ADR ಗಾಗಿ ಮುಂದಿನ ಹಂತದ ಪರಿಕಲ್ಪನೆಗಳು
- ವಾಸ್ತುಶಿಲ್ಪ ರೇಖಾಚಿತ್ರಗಳು, ನೋಟಗಳು ಮತ್ತು ದೃಷ್ಟಿಕೋನಗಳು
- ಕೋಡ್ ರೂಪದ ನಿರ್ಧಾರಗಳಿಗೆ ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು
- ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ಬಳಕೆಗೆ ನಿರ್ಧಾರ ರಕ್ಷಕಗಳು
- ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ
ಟೆಂಪ್ಲೇಟುಗಳು:
- ಜೆಫ್ ಟೈರೀ ಮತ್ತು ಆರ್ಟ್ ಅಕರ್ಮನ್ ಅವರ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- ಮೈಕೆಲ್ ನೈಗಾರ್ಡ್ ಅವರ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- EdgeX ನ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- arc42 ನ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- ಅಲೆಕ್ಸಾಂಡ್ರಿಯನ್ ಮಾದರಿಗಾಗಿ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- ವ್ಯಾಪಾರ ಪ್ರಕರಣಕ್ಕಾಗಿ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- MADR ಯೋಜನೆಯ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- Planguage ಬಳಸುವ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- Paulo Merson ಅವರ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- Olaf Zimmermann ಅವರ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- ಗರೆತ್ ಮಾರ್ಗನ್ ಅವರ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- GIG Cymru NHS Wales ನ ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
- Ignacio Larrañaga ಅವರ ಪ್ರಮುಖ ತಾಂತ್ರಿಕ ನಿರ್ಧಾರಗಳ (ITD) ನಿರ್ಧಾರ ದಾಖಲೆ ಟೆಂಪ್ಲೇಟು
ಉದಾಹರಣೆಗಳು:
- CSS ಚೌಕಟ್ಟು
- ಪರಿಸರ ಚರ ಸಂರಚನೆ
- ಮೆಟ್ರಿಕ್, ಮಾನಿಟರ್, ಎಚ್ಚರಿಕೆಗಳು
- Microsoft Azure DevOps
- Monorepo ವರ್ಸಸ್ multirepo
- ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳು
- ರಹಸ್ಯ ಸಂಗ್ರಹಣೆ
- ಸಮಯಮುದ್ರೆ ಸ್ವರೂಪ
- ಇನ್ನಷ್ಟು...
ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ ಎಂದರೇನು?
ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ (ADR) ಎಂದರೆ ಮಾಡಿದ ಒಂದು ಪ್ರಮುಖ ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರವನ್ನು ಅದರ ಸಂದರ್ಭ ಮತ್ತು ಪರಿಣಾಮಗಳೊಂದಿಗೆ ಸೆರೆಹಿಡಿಯುವ ದಾಖಲೆ.
ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ (AD) ಎಂದರೆ ಒಂದು ಮಹತ್ವದ ಅವಶ್ಯಕತೆಯನ್ನು ಪರಿಹರಿಸುವ ತಂತ್ರಾಂಶ ವಿನ್ಯಾಸ ಆಯ್ಕೆ.
ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ಲಾಗ್ (ADL) ಎಂದರೆ ನಿರ್ದಿಷ್ಟ ಯೋಜನೆಗೆ (ಅಥವಾ ಸಂಸ್ಥೆಗೆ) ರಚಿಸಿ ನಿರ್ವಹಿಸಲಾದ ಎಲ್ಲಾ ADR ಗಳ ಸಂಗ್ರಹ.
ವಾಸ್ತುಶಿಲ್ಪದ ದೃಷ್ಟಿಯಿಂದ ಮಹತ್ವದ ಅವಶ್ಯಕತೆ (ASR) ಎಂದರೆ ತಂತ್ರಾಂಶ ವ್ಯವಸ್ಥೆಯ ವಾಸ್ತುಶಿಲ್ಪದ ಮೇಲೆ ಅಳೆಯಬಹುದಾದ ಪರಿಣಾಮ ಬೀರುವ ಅವಶ್ಯಕತೆ.
ಇವೆಲ್ಲವೂ ವಾಸ್ತುಶಿಲ್ಪ ಜ್ಞಾನ ನಿರ್ವಹಣೆ (AKM) ಎಂಬ ವಿಷಯದ ವ್ಯಾಪ್ತಿಯಲ್ಲಿವೆ.
ಈ ದಾಖಲೆಯ ಗುರಿ, ADR ಗಳ ಬಗ್ಗೆ, ಅವುಗಳನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಎಂಬುದರ ಬಗ್ಗೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ ಎಲ್ಲಿ ನೋಡಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ ತ್ವರಿತ ಅವಲೋಕನವನ್ನು ಒದಗಿಸುವುದು.
ಸಂಕ್ಷಿಪ್ತ ರೂಪಗಳು:
AD: ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ
ADL: ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ಲಾಗ್
ADR: ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ
AKM: ವಾಸ್ತುಶಿಲ್ಪ ಜ್ಞಾನ ನಿರ್ವಹಣೆ
ASR: ವಾಸ್ತುಶಿಲ್ಪದ ದೃಷ್ಟಿಯಿಂದ ಮಹತ್ವದ ಅವಶ್ಯಕತೆ
ADR ಬಳಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ
ADR ಗಳನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲು, ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳೊಂದಿಗೆ ಈ ವಿಷಯಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಿ.
ನಿರ್ಧಾರ ಗುರುತಿಸುವಿಕೆ:
AD ಎಷ್ಟು ತುರ್ತು ಮತ್ತು ಎಷ್ಟು ಮುಖ್ಯ?
ಅದನ್ನು ಈಗಲೇ ಮಾಡಬೇಕೇ, ಅಥವಾ ಹೆಚ್ಚು ತಿಳಿಯುವವರೆಗೆ ಕಾಯಬಹುದೇ?
ವೈಯಕ್ತಿಕ ಮತ್ತು ಸಾಮೂಹಿಕ ಅನುಭವ, ಹಾಗೂ ಮಾನ್ಯತೆ ಪಡೆದ ವಿನ್ಯಾಸ ವಿಧಾನಗಳು ಮತ್ತು ಅಭ್ಯಾಸಗಳು ನಿರ್ಧಾರ ಗುರುತಿಸುವಿಕೆಗೆ ಸಹಾಯ ಮಾಡಬಹುದು.
ಆದರ್ಶವಾಗಿ, ಉತ್ಪನ್ನದ ಮಾಡಬೇಕಾದ ಕೆಲಸಗಳ ಪಟ್ಟಿಗೆ ಪೂರಕವಾದ ನಿರ್ಧಾರಗಳ ಮಾಡಬೇಕಾದ ಕೆಲಸಗಳ ಪಟ್ಟಿಯನ್ನು ನಿರ್ವಹಿಸಿ.
ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವಿಕೆ:
ಸಾಮಾನ್ಯ ತಂತ್ರಗಳು ಮತ್ತು ತಂತ್ರಾಂಶ ವಾಸ್ತುಶಿಲ್ಪ-ನಿರ್ದಿಷ್ಟ ತಂತ್ರಗಳು ಸೇರಿದಂತೆ, ಉದಾಹರಣೆಗೆ ಸಂವಾದ ನಕ್ಷೆ (dialogue mapping), ಹಲವಾರು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವ ತಂತ್ರಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ.
ಗುಂಪು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುವಿಕೆ ಒಂದು ಸಕ್ರಿಯ ಸಂಶೋಧನಾ ವಿಷಯ.
ನಿರ್ಧಾರ ಜಾರಿ ಮತ್ತು ಜಾರಿಗೊಳಿಸುವಿಕೆ:
AD ಗಳನ್ನು ತಂತ್ರಾಂಶ ವಿನ್ಯಾಸದಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ; ಆದ್ದರಿಂದ ಅವನ್ನು ವ್ಯವಸ್ಥೆಗೆ ಹಣ ಒದಗಿಸುವ, ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ಪಾಲುದಾರರಿಗೆ ತಿಳಿಸಬೇಕು ಮತ್ತು ಅವರಿಂದ ಒಪ್ಪಿಗೆ ಪಡೆಯಬೇಕು.
ವಾಸ್ತುಶಿಲ್ಪದ ದೃಷ್ಟಿಯಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣುವ ಕೋಡಿಂಗ್ ಶೈಲಿಗಳು ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪ ಕಾಳಜಿಗಳು ಹಾಗೂ ನಿರ್ಧಾರಗಳ ಮೇಲೆ ಗಮನಹರಿಸುವ ಕೋಡ್ ಪರಿಶೀಲನೆಗಳು ಎರಡು ಸಂಬಂಧಿತ ಅಭ್ಯಾಸಗಳು.
ತಂತ್ರಾಂಶ ವಿಕಸನದಲ್ಲಿ ತಂತ್ರಾಂಶ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಧುನೀಕರಿಸುವಾಗ AD ಗಳನ್ನು ಸಹ ಮರುಪರಿಗಣಿಸಬೇಕು.
ನಿರ್ಧಾರ ಹಂಚಿಕೆ (ಐಚ್ಛಿಕ):
ಅನೇಕ AD ಗಳು ಯೋಜನೆಗಳಾದ್ಯಂತ ಪುನರಾವರ್ತಿತವಾಗುತ್ತವೆ.
ಆದ್ದರಿಂದ, ಸ್ಪಷ್ಟ ಜ್ಞಾನ ನಿರ್ವಹಣೆ ತಂತ್ರವನ್ನು ಬಳಸುವಾಗ, ಹಿಂದಿನ ನಿರ್ಧಾರಗಳ ಉತ್ತಮ ಮತ್ತು ಕೆಟ್ಟ ಅನುಭವಗಳು ಮರುಬಳಸಬಹುದಾದ ಮೌಲ್ಯಯುತ ಸಂಪತ್ತಾಗಬಲ್ಲವು.
ನಿರ್ಧಾರ ದಾಖಲಾತಿ:
ನಿರ್ಧಾರಗಳನ್ನು ಸೆರೆಹಿಡಿಯಲು ಅನೇಕ ಟೆಂಪ್ಲೇಟುಗಳು ಮತ್ತು ಸಾಧನಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ.
ಚುರುಕು (agile) ಸಮುದಾಯಗಳನ್ನು ನೋಡಿ, ಉದಾ. M. Nygard ಅವರ ADR ಗಳು.
ಸಾಂಪ್ರದಾಯಿಕ ತಂತ್ರಾಂಶ ಎಂಜಿನಿಯರಿಂಗ್ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪ ವಿನ್ಯಾಸ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನೋಡಿ, ಉದಾ. IBM UMF ಮತ್ತು CapitalOne ನ Tyree ಮತ್ತು Akerman ಸೂಚಿಸಿದ ಕೋಷ್ಟಕ ವಿನ್ಯಾಸಗಳು.
ಇನ್ನಷ್ಟು:
- ಮೇಲಿನ ಹಂತಗಳನ್ನು Wikipedia ದ Architectural Decision ನಮೂದಿನಿಂದ ಅಳವಡಿಸಿಕೊಳ್ಳಲಾಗಿದೆ
ಸಾಧನಗಳೊಂದಿಗೆ ADR ಬಳಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ
- MySpec — ಯೋಜನೆಯ ಸಂವಿಧಾನ, ತಾಂತ್ರಿಕ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ADR ಗಳನ್ನು MCP ಮೂಲಕ ಒದಗಿಸಲಾಗುವ ಸ್ವಚ್ಛ Markdown ಆಗಿ ರೂಪಿಸುವ ಸ್ವಯಂಚಾಲಿತ ವಿಶೇಷಣ ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ವೇದಿಕೆ.
ನೀವು ಬಯಸಿದ ರೀತಿಯಲ್ಲಿ ಸಾಧನಗಳೊಂದಿಗೆ ADR ಬಳಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು.
ಉದಾಹರಣೆಗೆ:
ನೀವು Google Drive ಮತ್ತು ಆನ್ಲೈನ್ ಸಂಪಾದನೆಯನ್ನು ಇಷ್ಟಪಡುವುದಾದರೆ, Google Doc ಅಥವಾ Google Sheet ರಚಿಸಬಹುದು.
ನೀವು git ನಂತಹ ಮೂಲ ಕೋಡ್ ಆವೃತ್ತಿ ನಿಯಂತ್ರಣವನ್ನು ಬಳಸಲು ಇಷ್ಟಪಡುವುದಾದರೆ, ಪ್ರತಿ ADR ಗೂ ಒಂದು ಕಡತ ರಚಿಸಬಹುದು.
ನೀವು Atlassian Jira ನಂತಹ ಯೋಜನಾ ಯೋಜನೆ ಸಾಧನಗಳನ್ನು ಬಳಸಲು ಇಷ್ಟಪಡುವುದಾದರೆ, ಆ ಸಾಧನದ ಯೋಜನಾ ಟ್ರ್ಯಾಕರ್ ಬಳಸಬಹುದು.
ನೀವು MediaWiki ನಂತಹ ವಿಕಿಗಳನ್ನು ಬಳಸಲು ಇಷ್ಟಪಡುವುದಾದರೆ, ADR ವಿಕಿ ರಚಿಸಬಹುದು.
git ನೊಂದಿಗೆ ADR ಬಳಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ
ನೀವು git ಆವೃತ್ತಿ ನಿಯಂತ್ರಣವನ್ನು ಬಳಸಲು ಇಷ್ಟಪಡುವುದಾದರೆ, ಮೂಲ ಕೋಡ್ ಇರುವ ಒಂದು ಸಾಮಾನ್ಯ ತಂತ್ರಾಂಶ ಯೋಜನೆಗಾಗಿ git ನೊಂದಿಗೆ ADR ಬಳಸಲು ನಾವು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಲು ಇಷ್ಟಪಡುತ್ತೇವೆ ಎಂಬುದು ಇಲ್ಲಿದೆ.
ADR ಕಡತಗಳಿಗಾಗಿ ಒಂದು ಡೈರೆಕ್ಟರಿ ರಚಿಸಿ:
$ mkdir adr
ಪ್ರತಿ ADR ಗೂ choose-database.md ನಂತಹ ಒಂದು ಪಠ್ಯ ಕಡತವನ್ನು ರಚಿಸಿ:
$ vi choose-database.md
ADR ನಲ್ಲಿ ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಬರೆಯಿರಿ. ಕಲ್ಪನೆಗಳಿಗಾಗಿ ಈ ರೆಪೊಸಿಟರಿಯಲ್ಲಿರುವ ಟೆಂಪ್ಲೇಟುಗಳನ್ನು ನೋಡಿ.
ADR ಅನ್ನು ನಿಮ್ಮ git ರೆಪೊಗೆ ಕಮಿಟ್ ಮಾಡಿ.
ADR ಗಾಗಿ Claude Code ಕೌಶಲ್ಯಗಳು
ಈ ರೆಪೊಸಿಟರಿಯು skills/ ಅಡಿಯಲ್ಲಿ ಎರಡು Claude Code ಕೌಶಲ್ಯಗಳನ್ನು (skills) ಒದಗಿಸುತ್ತದೆ, ಇದರಿಂದ AI ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ಗಳು ಈ ಯೋಜನೆ ಶಿಫಾರಸು ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ADR ಗಳನ್ನು ಬರೆಯಬಹುದು ಮತ್ತು ನಿರ್ವಹಿಸಬಹುದು:
architecture-decision-record-skill— ಯಾವುದೇ ಯೋಜನೆಯಲ್ಲಿ ADR ಗಳನ್ನು ಬರೆಯುವ ಯಾರಿಗಾದರೂ ಸಾಮಾನ್ಯ ಬಳಕೆಗೆ. ನಿರ್ಧಾರಕ್ಕೆ ADR ಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಲು,adr/ಅಥವಾdecisions/ಡೈರೆಕ್ಟರಿ ಸಿದ್ಧಪಡಿಸಲು, ಕಡತಗಳಿಗೆ ಹೆಸರಿಡಲು, ಒಳಗೊಂಡ ಹನ್ನೊಂದು ಚೌಕಟ್ಟುಗಳಿಂದ ಟೆಂಪ್ಲೇಟು ಆರಿಸಲು, ಮತ್ತು ಗಟ್ಟಿಯಾದ ಸಂದರ್ಭ/ನಿರ್ಧಾರ/ಪರಿಣಾಮಗಳ ವಿಭಾಗಗಳನ್ನು ಬರೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.architecture-decision-record-maintainer-skill— ಈ ರೆಪೊಸಿಟರಿಯ ನಿರ್ವಾಹಕರಿಗೆ ವಿಶೇಷ. ರೆಪೊಸಿಟರಿ ವಿನ್ಯಾಸ, README/locales ಪ್ರತಿಬಿಂಬಿಸುವ ಸಂಪ್ರದಾಯಗಳು, ಮತ್ತು ಹೊಸ ಟೆಂಪ್ಲೇಟು, ಉದಾಹರಣೆ ಅಥವಾ ಸಾಧನ ಲಿಂಕ್ ಸೇರಿಸುವ ನಿಖರ ಹಂತಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ.
ಕೌಶಲ್ಯವನ್ನು ಬಳಸಲು, ಕೌಶಲ್ಯದ ಫೋಲ್ಡರ್ ಅನ್ನು ನೀವು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ರೆಪೊಸಿಟರಿಯ ಮೂಲದ .claude/skills/ ಗೆ (ಅಥವಾ ಪ್ರತಿ ಯೋಜನೆಯಲ್ಲೂ ಲಭ್ಯವಾಗಿಸಲು ~/.claude/skills/ ಗೆ) ನಕಲಿಸಿ, ನಂತರ Claude Code ಗೆ ADR ಬರೆಯಲು ಅಥವಾ ಪರಿಶೀಲಿಸಲು ಕೇಳಿ.
ADR ಗಾಗಿ ಕಡತ ಹೆಸರು ಸಂಪ್ರದಾಯಗಳು
ನೀವು ಸಾಮಾನ್ಯ ಪಠ್ಯ ಕಡತಗಳನ್ನು ಬಳಸಿ ADR ಗಳನ್ನು ರಚಿಸಲು ಆರಿಸಿಕೊಂಡರೆ, ನಿಮ್ಮದೇ ಆದ ADR ಕಡತ ಹೆಸರು ಸಂಪ್ರದಾಯವನ್ನು ರೂಪಿಸಲು ನೀವು ಬಯಸಬಹುದು.
ನಾವು ನಿರ್ದಿಷ್ಟ ಸ್ವರೂಪವಿರುವ ಕಡತ ಹೆಸರು ಸಂಪ್ರದಾಯವನ್ನು ಬಳಸಲು ಇಷ್ಟಪಡುತ್ತೇವೆ.
ಉದಾಹರಣೆಗಳು:
choose-database.md
format-timestamps.md
manage-passwords.md
handle-exceptions.md
ನಮ್ಮ ಕಡತ ಹೆಸರು ಸಂಪ್ರದಾಯ:
ಹೆಸರು ವರ್ತಮಾನ ಕಾಲದ ಆಜ್ಞಾರ್ಥಕ ಕ್ರಿಯಾಪದ ಪದಗುಚ್ಛವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಇದು ಓದಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಕಮಿಟ್ ಸಂದೇಶ ಸ್ವರೂಪಕ್ಕೆ ಹೊಂದುತ್ತದೆ.
ಹೆಸರು ಸಣ್ಣ ಅಕ್ಷರಗಳು ಮತ್ತು ಡ್ಯಾಶ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ (ಈ ರೆಪೊದಂತೆಯೇ). ಇದು ಓದುವಿಕೆ ಮತ್ತು ವ್ಯವಸ್ಥೆಯ ಬಳಕೆಯ ಸುಲಭತೆಯ ನಡುವಿನ ಸಮತೋಲನ.
ವಿಸ್ತರಣೆ markdown. ಇದು ಸುಲಭ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ಗೆ ಉಪಯುಕ್ತವಾಗಬಹುದು.
ಉತ್ತಮ ADR ಗಳನ್ನು ಬರೆಯಲು ಸಲಹೆಗಳು
ಉತ್ತಮ ADR ನ ಲಕ್ಷಣಗಳು:
ತಾರ್ಕಿಕತೆ: ನಿರ್ದಿಷ್ಟ AD ಯನ್ನು ಮಾಡುವುದರ ಕಾರಣಗಳನ್ನು ವಿವರಿಸಿ. ಇದರಲ್ಲಿ ಸಂದರ್ಭ (ಕೆಳಗೆ ನೋಡಿ), ವಿವಿಧ ಸಂಭಾವ್ಯ ಆಯ್ಕೆಗಳ ಸಾಧಕ-ಬಾಧಕಗಳು, ವೈಶಿಷ್ಟ್ಯ ಹೋಲಿಕೆಗಳು, ವೆಚ್ಚ/ಲಾಭ ಚರ್ಚೆಗಳು ಮತ್ತು ಇನ್ನಷ್ಟು ಸೇರಬಹುದು.
ನಿರ್ದಿಷ್ಟತೆ: ಪ್ರತಿ ADR ಒಂದೇ AD ಯ ಬಗ್ಗೆ ಇರಬೇಕು, ಹಲವು AD ಗಳ ಬಗ್ಗೆ ಅಲ್ಲ.
ಸಮಯಮುದ್ರೆಗಳು: ADR ನಲ್ಲಿನ ಪ್ರತಿ ಅಂಶವನ್ನು ಯಾವಾಗ ಬರೆಯಲಾಯಿತು ಎಂಬುದನ್ನು ಗುರುತಿಸಿ. ವೆಚ್ಚಗಳು, ವೇಳಾಪಟ್ಟಿಗಳು, ವಿಸ್ತರಣೆ ಮತ್ತು ಇಂತಹವುಗಳಂತೆ ಕಾಲಕ್ರಮೇಣ ಬದಲಾಗಬಹುದಾದ ಅಂಶಗಳಿಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯ.
ಬದಲಾಯಿಸಲಾಗದ್ದು: ADR ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮಾಹಿತಿಯನ್ನು ಬದಲಿಸಬೇಡಿ. ಬದಲಿಗೆ, ಹೊಸ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ADR ಅನ್ನು ತಿದ್ದುಪಡಿ ಮಾಡಿ, ಅಥವಾ ಹೊಸ ADR ರಚಿಸುವ ಮೂಲಕ ADR ಅನ್ನು ಅತಿಕ್ರಮಿಸಿ.
ADR ನಲ್ಲಿನ ಉತ್ತಮ "ಸಂದರ್ಭ" ವಿಭಾಗದ ಲಕ್ಷಣಗಳು:
ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಪರಿಸ್ಥಿತಿ ಮತ್ತು ವ್ಯವಹಾರ ಆದ್ಯತೆಗಳನ್ನು ವಿವರಿಸಿ.
ನಿಮ್ಮ ತಂಡಗಳ ಸಾಮಾಜಿಕ ಮತ್ತು ಕೌಶಲ್ಯ ಸಂಯೋಜನೆಯ ಆಧಾರದ ಮೇಲಿನ ತರ್ಕ ಮತ್ತು ಪರಿಗಣನೆಗಳನ್ನು ಸೇರಿಸಿ.
ಪ್ರಸ್ತುತವಾದ ಸಾಧಕ-ಬಾಧಕಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಅಗತ್ಯಗಳು ಹಾಗೂ ಗುರಿಗಳಿಗೆ ಹೊಂದುವ ರೀತಿಯಲ್ಲಿ ಅವನ್ನು ವಿವರಿಸಿ.
ADR ನಲ್ಲಿನ ಉತ್ತಮ "ಪರಿಣಾಮಗಳು" ವಿಭಾಗದ ಲಕ್ಷಣಗಳು:
ನಿರ್ಧಾರ ಮಾಡುವುದರಿಂದ ಏನು ಅನುಸರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸಿ. ಇದರಲ್ಲಿ ಪರಿಣಾಮಗಳು, ಫಲಿತಾಂಶಗಳು, ಉತ್ಪನ್ನಗಳು, ಅನುಸರಣೆಗಳು ಮತ್ತು ಇನ್ನಷ್ಟು ಸೇರಬಹುದು.
ನಂತರದ ಯಾವುದೇ ADR ಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸಿ. ಒಂದು ADR ಹೆಚ್ಚಿನ ADR ಗಳ ಅಗತ್ಯವನ್ನು ಹುಟ್ಟುಹಾಕುವುದು ತುಲನಾತ್ಮಕವಾಗಿ ಸಾಮಾನ್ಯ; ಉದಾಹರಣೆಗೆ ಒಂದು ADR ದೊಡ್ಡ ಸಮಗ್ರ ಆಯ್ಕೆಯನ್ನು ಮಾಡಿದಾಗ, ಅದು ಇನ್ನೂ ಹಲವು ಸಣ್ಣ ನಿರ್ಧಾರಗಳ ಅಗತ್ಯವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಯಾವುದೇ ಕ್ರಿಯೆಯ ನಂತರದ ಪರಿಶೀಲನೆ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸೇರಿಸಿ. ಕಲಿಯಲು ಮತ್ತು ಬೆಳೆಯಲು, ADR ಮಾಹಿತಿಯನ್ನು ವಾಸ್ತವದಲ್ಲಿ ನಡೆದುದರೊಂದಿಗೆ ಹೋಲಿಸಲು ತಂಡಗಳು ಒಂದು ತಿಂಗಳ ನಂತರ ಪ್ರತಿ ADR ಅನ್ನು ಪರಿಶೀಲಿಸುವುದು ವಿಶಿಷ್ಟ.
ಹೊಸ ADR ಹಿಂದಿನ ADR ನ ಸ್ಥಾನವನ್ನು ಪಡೆಯಬಹುದು:
- ಹಿಂದಿನ ADR ಅನ್ನು ಬದಲಾಯಿಸುವ ಅಥವಾ ಅಮಾನ್ಯಗೊಳಿಸುವ AD ಮಾಡಿದಾಗ, ಹೊಸ ADR ರಚಿಸಬೇಕು
ADR ಉದಾಹರಣೆ ಟೆಂಪ್ಲೇಟುಗಳು
ನಾವು ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ ADR ಉದಾಹರಣೆ ಟೆಂಪ್ಲೇಟುಗಳು:
ಮೈಕೆಲ್ ನೈಗಾರ್ಡ್ ಅವರ ADR ಟೆಂಪ್ಲೇಟು (ಸರಳ ಮತ್ತು ಜನಪ್ರಿಯ)
ಜೆಫ್ ಟೈರೀ ಮತ್ತು ಆರ್ಟ್ ಅಕರ್ಮನ್ ಅವರ ADR ಟೆಂಪ್ಲೇಟು (ಹೆಚ್ಚು ಸುಧಾರಿತ)
ಅಲೆಕ್ಸಾಂಡ್ರಿಯನ್ ಮಾದರಿಗಾಗಿ ADR ಟೆಂಪ್ಲೇಟು (ಸಂದರ್ಭದ ವಿವರಗಳೊಂದಿಗೆ ಸರಳ)
ವ್ಯಾಪಾರ ಪ್ರಕರಣಕ್ಕಾಗಿ ADR ಟೆಂಪ್ಲೇಟು (ವೆಚ್ಚಗಳು, SWOT ಮತ್ತು ಹೆಚ್ಚಿನ ಅಭಿಪ್ರಾಯಗಳೊಂದಿಗೆ ಹೆಚ್ಚು MBA-ಕೇಂದ್ರಿತ)
Markdown Any Decision Records (MADR) ಯೋಜನೆಯ ADR ಟೆಂಪ್ಲೇಟು (ಸರಳ ಮತ್ತು ವಿವರವಾದ ಎರಡೂ ಆವೃತ್ತಿಗಳು; ನಂತರದ್ದು ಆಯ್ಕೆಗಳು ಮತ್ತು ಅವುಗಳ ಸಾಧಕ-ಬಾಧಕಗಳಿಗೆ ಒತ್ತು ನೀಡುತ್ತದೆ)
Planguage ಬಳಸುವ ADR ಟೆಂಪ್ಲೇಟು (ಹೆಚ್ಚು ಗುಣಮಟ್ಟ ಭರವಸೆ-ಕೇಂದ್ರಿತ)
Ignacio Larrañaga ಅವರ ಪ್ರಮುಖ ತಾಂತ್ರಿಕ ನಿರ್ಧಾರಗಳ (ITD) ಟೆಂಪ್ಲೇಟು (ಲೀನ್ ಮತ್ತು ನಿರ್ಧಾರ-ಮೊದಲ, ತ್ವರಿತ ಕಾರ್ಯನಿರ್ವಾಹಕ ಪರಿಶೀಲನೆಗೆ ಅತ್ಯುತ್ತಮೀಕರಿಸಲಾಗಿದೆ)
ADR ಗಾಗಿ ತಂಡಕಾರ್ಯ ಸಲಹೆ
ನಿಮ್ಮ ತಂಡದೊಂದಿಗೆ ನಿರ್ಧಾರ ದಾಖಲೆಗಳನ್ನು ಬಳಸುವುದನ್ನು ನೀವು ಪರಿಗಣಿಸುತ್ತಿದ್ದರೆ, ಅನೇಕ ತಂಡಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಮೂಲಕ ನಾವು ಕಲಿತ ಕೆಲವು ಸಲಹೆಗಳು ಇಲ್ಲಿವೆ.
"ಏನು" ಎಂದು ಆದೇಶಿಸುವ ಬದಲು "ಏಕೆ" ಎಂಬುದರ ಬಗ್ಗೆ ಒಟ್ಟಾಗಿ ಮಾತನಾಡುವ ಮೂಲಕ ನಿಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳನ್ನು ಮುನ್ನಡೆಸುವ ಅವಕಾಶ ನಿಮಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನಿರ್ಧಾರ ದಾಖಲೆಗಳು ತಂಡಗಳು ಚಾಣಾಕ್ಷತೆಯಿಂದ ಯೋಚಿಸಲು ಮತ್ತು ಉತ್ತಮವಾಗಿ ಸಂವಹನ ನಡೆಸಲು ಒಂದು ದಾರಿ; ನಿರ್ಧಾರ ದಾಖಲೆಗಳು ಕೇವಲ ಕೆಲಸ ಮುಗಿದ ಮೇಲೆ ಒತ್ತಾಯಪೂರ್ವಕವಾಗಿ ಮಾಡುವ ಕಾಗದಪತ್ರದ ಅವಶ್ಯಕತೆಯಾಗಿದ್ದರೆ ಅವುಗಳಿಗೆ ಮೌಲ್ಯವಿರುವುದಿಲ್ಲ.
ಕೆಲವು ತಂಡಗಳು "ADR" ಎಂಬ ಸಂಕ್ಷಿಪ್ತ ರೂಪಕ್ಕಿಂತ "ನಿರ್ಧಾರಗಳು" ಎಂಬ ಹೆಸರನ್ನು ಹೆಚ್ಚು ಇಷ್ಟಪಡುತ್ತವೆ. ಕೆಲವು ತಂಡಗಳು "decisions" ಎಂಬ ಡೈರೆಕ್ಟರಿ ಹೆಸರನ್ನು ಬಳಸಿದಾಗ, ಒಂದು ದೀಪ ಹೊತ್ತಿಕೊಂಡಂತಾಗಿ, ತಂಡವು ಮಾರಾಟಗಾರರ ನಿರ್ಧಾರಗಳು, ಯೋಜನೆ ನಿರ್ಧಾರಗಳು, ವೇಳಾಪಟ್ಟಿ ನಿರ್ಧಾರಗಳು ಇತ್ಯಾದಿಗಳಂತಹ ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಆ ಡೈರೆಕ್ಟರಿಗೆ ಹಾಕಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಈ ಎಲ್ಲಾ ರೀತಿಯ ಮಾಹಿತಿಯು ಒಂದೇ ಟೆಂಪ್ಲೇಟನ್ನು ಬಳಸಬಹುದು. ಸಂಕ್ಷಿಪ್ತ ರೂಪಗಳಿಗಿಂತ ("ADR") ಪದಗಳಿಂದ ("ನಿರ್ಧಾರಗಳು") ಜನರು ವೇಗವಾಗಿ ಕಲಿಯುತ್ತಾರೆ, "ದಾಖಲೆ" ಎಂಬ ಪದವನ್ನು ತೆಗೆದುಹಾಕಿದಾಗ ಜನರು ಪ್ರಗತಿಯಲ್ಲಿರುವ ದಾಖಲೆಗಳನ್ನು ಬರೆಯಲು ಹೆಚ್ಚು ಪ್ರೇರಿತರಾಗುತ್ತಾರೆ, ಮತ್ತು ಕೆಲವು ಡೆವಲಪರ್ಗಳು ಹಾಗೂ ಕೆಲವು ವ್ಯವಸ್ಥಾಪಕರು "ವಾಸ್ತುಶಿಲ್ಪ" ಎಂಬ ಪದವನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ ಎಂದು ನಾವು ಊಹಿಸುತ್ತೇವೆ.
ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಬದಲಾಯಿಸಲಾಗದಿರುವುದು ಆದರ್ಶ. ಆಚರಣೆಯಲ್ಲಿ, ಬದಲಾಯಿಸಬಹುದಾದಿರುವುದು ನಮ್ಮ ತಂಡಗಳಿಗೆ ಉತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ. ನಾವು ಹೊಸ ಮಾಹಿತಿಯನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ADR ಗೆ ದಿನಾಂಕ ಮುದ್ರೆಯೊಂದಿಗೆ ಮತ್ತು ಆ ಮಾಹಿತಿಯು ನಿರ್ಧಾರದ ನಂತರ ಬಂದಿದೆ ಎಂಬ ಟಿಪ್ಪಣಿಯೊಂದಿಗೆ ಸೇರಿಸುತ್ತೇವೆ. ಈ ರೀತಿಯ ವಿಧಾನವು ನಾವೆಲ್ಲರೂ ನವೀಕರಿಸಬಹುದಾದ "ಜೀವಂತ ದಾಖಲೆ" ಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಹೊಸ ಸಹೋದ್ಯೋಗಿಗಳಿಂದ, ಅಥವಾ ಹೊಸ ಕೊಡುಗೆಗಳಿಂದ, ಅಥವಾ ನಮ್ಮ ಬಳಕೆಗಳ ನೈಜ ಫಲಿತಾಂಶಗಳಿಂದ, ಅಥವಾ ಮಾರಾಟಗಾರರ ಸಾಮರ್ಥ್ಯಗಳು, ಬೆಲೆ ಯೋಜನೆಗಳು, ಪರವಾನಗಿ ಒಪ್ಪಂದಗಳು ಮುಂತಾದ ನಂತರದ ಮೂರನೇ ಪಕ್ಷದ ಬದಲಾವಣೆಗಳಿಂದ ಮಾಹಿತಿ ಸಿಕ್ಕಾಗ ವಿಶಿಷ್ಟವಾಗಿ ನವೀಕರಣಗಳು ನಡೆಯುತ್ತವೆ.
ADR ಗಾಗಿ ತಂಡಕಾರ್ಯ ಪ್ರಶ್ನೆಗಳು
ADR ಅನ್ನು ಯಾರು ರಚಿಸಬಹುದು?
ನಿರ್ದಿಷ್ಟ ವ್ಯಕ್ತಿಗಳು, ನಿರ್ದಿಷ್ಟ ಪಾತ್ರಗಳು, ನಿರ್ದಿಷ್ಟ ತಂಡಗಳು ಅಥವಾ ನಿರ್ದಿಷ್ಟ ವಿಭಾಗಗಳಂತಹ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ; ಜೊತೆಗೆ ADR ಅನ್ನು ನಿಯೋಜಿಸಬಲ್ಲ, ಅಂದರೆ ಬೇರೊಬ್ಬರು ಬರೆಯುವ ADR ಅನ್ನು ವಿನಂತಿಸಬಲ್ಲ ವ್ಯಕ್ತಿಗಳು, ಪಾತ್ರಗಳು, ತಂಡಗಳು ಅಥವಾ ವಿಭಾಗಗಳು ಇವೆಯೇ ಎಂಬುದನ್ನೂ ಪರಿಗಣಿಸಿ.
ಉದಾಹರಣೆ ಉತ್ತರ: ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆ README ಪುಟವನ್ನು ಓದಿರುವ ನಮ್ಮ ಸಂಸ್ಥೆಯ ಯಾವುದೇ ವ್ಯಕ್ತಿ ADR ಅನ್ನು ಪ್ರಸ್ತಾಪಿಸಬಹುದು, ಅಂದರೆ ಆ ವ್ಯಕ್ತಿ ಅದನ್ನು ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿ ತಂಡದೊಂದಿಗೆ ಹಂಚಿಕೊಳ್ಳಬಹುದು.
ADR ಅನ್ನು ಎತ್ತುವುದನ್ನು ಯಾವುದು ಸಮರ್ಥಿಸುತ್ತದೆ?
ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ತಂಡದ ಕೆಲಸದ ವಿಧಾನಗಳು, ನಿಮ್ಮ ತಂತ್ರಾಂಶ ವ್ಯವಸ್ಥೆಯ ರಚನೆ, ತಂಡಗಳ ನಡುವಿನ ಸಮನ್ವಯ, ದೀರ್ಘಕಾಲೀನ ನಿರ್ವಹಣಾ ಸಾಮರ್ಥ್ಯ, ಬಾಹ್ಯ ಇಂಟರ್ಫೇಸ್ಗಳು, ಯಾರಿಗೆ ಪ್ರಯೋಜನವಾಗಬೇಕೆಂದು ನೀವು ಬಯಸುತ್ತೀರಿ ಮತ್ತು ಇಂತಹವುಗಳಂತಹ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ.
ಉದಾಹರಣೆ ಉತ್ತರ: ನಾವು ಮಾಡುತ್ತಿರುವುದರ "ಏಕೆ" ಎಂಬುದನ್ನು ಭವಿಷ್ಯದ ಡೆವಲಪರ್ಗಳು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕೆಂದು ನಾವು ಬಯಸಿದಾಗ ADR ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ.
ADR ಅನ್ನು ಎತ್ತದಿರುವುದನ್ನು ಯಾವುದು ಸಮರ್ಥಿಸುತ್ತದೆ?
ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ಅಲ್ಲದ ನಿರ್ಧಾರಗಳು, ಅಥವಾ ಕನಿಷ್ಠ ಅಪಾಯದ ಅಥವಾ ಸ್ವಯಂಪೂರ್ಣ ಅಥವಾ ಒಬ್ಬನೇ ಡೆವಲಪರ್ಗೆ ಸಂಬಂಧಿಸಿದಂತಹ ಸಣ್ಣ ನಿರ್ಧಾರಗಳು, ಅಥವಾ ಮಾನದಂಡಗಳು ಅಥವಾ ನೀತಿಗಳು ಅಥವಾ ದಾಖಲಾತಿಯಂತಹವುಗಳಿಂದ ಈಗಾಗಲೇ ಬೇರೆಡೆ ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಂಡಿರುವ ನಿರ್ಧಾರಗಳು, ಅಥವಾ ತಾತ್ಕಾಲಿಕ ಪರಿಹಾರಗಳು ಅಥವಾ ಪರಿಕಲ್ಪನೆಯ ಪುರಾವೆಗಳು ಅಥವಾ ಪ್ರಯೋಗಗಳಂತಹ ತಾತ್ಕಾಲಿಕ ನಿರ್ಧಾರಗಳಂತಹ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ.
ಉದಾಹರಣೆ ಉತ್ತರ: ನಿರ್ಧಾರವು ವ್ಯಾಪ್ತಿ, ಸಮಯ, ಅಪಾಯ ಮತ್ತು ವೆಚ್ಚದಲ್ಲಿ ಸೀಮಿತವಾಗಿದ್ದಾಗ, ಅಥವಾ ಈಗಾಗಲೇ ಬೇರೆಡೆ ಒಳಗೊಂಡಿದ್ದಾಗ ನಾವು ADR ಅನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಬಯಸುತ್ತೇವೆ.
ADR ನ ಜೀವನಚಕ್ರ ಯಾವುದು?
ರಚನೆ ಪ್ರಕ್ರಿಯೆ, ಸಂಶೋಧನೆ ಪ್ರಕ್ರಿಯೆ, ನಿರ್ಧಾರ ಪ್ರಕ್ರಿಯೆ, ಅನುಷ್ಠಾನ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಸೇವೆಯಿಂದ ನಿವೃತ್ತಿಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಯಂತಹ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ. ADR ಅನ್ನು ಒಂದು ಸ್ಥಿತಿಯಿಂದ ಮುಂದಿನ ಸ್ಥಿತಿಗೆ ಹೇಗೆ ಸರಿಸುವುದು ಮತ್ತು ಇದನ್ನು ಪಾಲುದಾರರಿಗೆ ಹೇಗೆ ತಿಳಿಸುವುದು ಎಂಬಂತೆ, ADR ಜೀವನಚಕ್ರವನ್ನು ಕಾಲಕ್ರಮೇಣ ಹೇಗೆ ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಎಂಬುದನ್ನೂ ಪರಿಗಣಿಸಿ.
ಉದಾಹರಣೆ ಉತ್ತರ: ADR ಐದು ಜೀವನಚಕ್ರ ಹಂತಗಳನ್ನು ಹೊಂದಿರಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ: ಪ್ರಾರಂಭಿಸುವುದು → ಸಂಶೋಧಿಸುವುದು → ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು → ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು → ನಿರ್ವಹಿಸುವುದು → ನಿವೃತ್ತಿಗೊಳಿಸುವುದು.
ADR ನ ಜೀವನಚಕ್ರ ಹಂತಗಳಿಗೆ ಮಾನದಂಡಗಳೇನು?
ADR ಗೆ ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳಂತಹ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ, ಅಂದರೆ ಒಂದು ಜೀವನಚಕ್ರ ಹಂತದಿಂದ ಮುಂದಿನ ಹಂತಕ್ಕೆ ಮುಂದುವರಿಯಲು ಅದು ಸಾಕಷ್ಟು ಉತ್ತಮವಾಗಿದೆ ಎಂದು ನಿಮಗೆ ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ? ಸಮಸ್ಯೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಲಾಗಿದೆಯೇ? ಪರ್ಯಾಯಗಳನ್ನು ಪರಿಗಣಿಸಲಾಗಿದೆಯೇ? ಸಾಧಕ-ಬಾಧಕ ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಸಾಕಷ್ಟು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಂಡು ದಾಖಲಿಸಲಾಗಿದೆಯೇ? ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಸಂದರ್ಭ ಇದೆಯೇ? ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಪಾಲುದಾರರು ಒಳಗೊಂಡಿದ್ದಾರೆಯೇ? ಎಲ್ಲಾ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಲಾಗಿದೆಯೇ?
ಉದಾಹರಣೆ ಉತ್ತರ: ಸಕ್ರಿಯ ತಂಡವು 1) ತನ್ನ ಸಂಶೋಧನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದಾಗ, 2) ತನ್ನ ಮೌಲ್ಯಮಾಪನವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದಾಗ, 3) ಅಭಿಪ್ರಾಯಗಳಿಗಾಗಿ ವಿನಂತಿ ಮತ್ತು ಒಂದು ವಾರದ ಸಮಯಮಿತಿಯೊಂದಿಗೆ ADR ಪ್ರಸ್ತಾವನೆಯನ್ನು ಪಾಲುದಾರರಿಗೆ ಪ್ರಕಟಿಸಿದಾಗ, 4) ಎಲ್ಲಾ ಪಾಲುದಾರರ ಅಭಿಪ್ರಾಯಗಳನ್ನು ಅಳವಡಿಸಿಕೊಂಡು ಪರಿಹರಿಸಿದಾಗ, ADR ಅನ್ನು ಪಾಲುದಾರರು ಮತದಾನ ಮಾಡಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ.
ADR ನೊಂದಿಗೆ ಯಾವ ಪಾತ್ರಗಳು ಮತ್ತು ಜವಾಬ್ದಾರಿಗಳು ಸಂವಹನ ನಡೆಸುತ್ತವೆ?
ಪ್ರಸ್ತಾಪಕ, ಸಂಶೋಧಕ, ಮೌಲ್ಯಮಾಪಕ, ಪರಿಶೀಲಕ, ಅನುಮೋದಕ, ನಿರ್ವಾಹಕ ಮತ್ತು ಇಂತಹವುಗಳಂತಹ ಪಾತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ. ಪಾಲುದಾರರೊಂದಿಗೆ ಸಂವಹನ, ನಿರೀಕ್ಷೆಗಳನ್ನು ಪೂರೈಸುವುದನ್ನು ಖಚಿತಪಡಿಸುವುದು, ವೆಬ್ಸೈಟ್ ಅಥವಾ ಇಂಟ್ರಾನೆಟ್ನಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳುವುದು ಮತ್ತು ಕೆಲಸವನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ಹಾಗೂ ವಿಶೇಷವಾಗಿ ಸಂಬಂಧಿತ ಬದಲಾವಣೆಗಳು ಸಂಭವಿಸಿದಾಗ ಪರಿಶೀಲಿಸುವುದು ಮುಂತಾದ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಪರಿಗಣಿಸಿ.
ಉದಾಹರಣೆ ಉತ್ತರ: ಪ್ರತಿ ADR ಗೂ ಯಾವಾಗಲೂ ಪ್ರಾಥಮಿಕ ಸಂಪರ್ಕ ವ್ಯಕ್ತಿ, ದ್ವಿತೀಯ ಸಂಪರ್ಕ ವ್ಯಕ್ತಿ ಮತ್ತು ಹೊಣೆಗಾರ ತಂಡ ಇರಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ; ಇವರು ಸಂವಹನ, ಪ್ರಕಟಣೆ, ನಿರ್ವಹಣೆ, ವರ್ಷಕ್ಕೆ ಕನಿಷ್ಠ ಒಮ್ಮೆ ನಿಯತಕಾಲಿಕ ಪರಿಶೀಲನೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಅಂತಿಮವಾಗಿ ನಿವೃತ್ತಿಗೊಳಿಸುವುದಕ್ಕೆ ಜವಾಬ್ದಾರರು.
ಆಡಳಿತವು ADR ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ?
ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಕೆಲಸದ ವಿಧಾನಗಳು, ಕಾನೂನು ಅಂಶಗಳು ಅಥವಾ ಮಾನವ ಸಂಪನ್ಮೂಲ ಅಂಶಗಳಂತಹ ಯಾವುದೇ ವಿಶೇಷ ಅನುಸರಣೆ ಅಗತ್ಯಗಳು, ಒಮ್ಮತ ಮತ್ತು ಸಂಘರ್ಷ ಮತ್ತು ಉನ್ನತ ಮಟ್ಟಕ್ಕೆ ಒಯ್ಯುವಿಕೆಯನ್ನು ನೀವು ಹೇಗೆ ನಿಭಾಯಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂಬಂತಹ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ. ADR ಅನ್ನು ಅನುಮೋದಿಸಲು, ಅಥವಾ ಅದರ ಮೇಲೆ ಮತ ಹಾಕಲು, ಅಥವಾ ಅದನ್ನು ವೀಟೋ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವಂತೆ, ADR ವಿಷಯದಲ್ಲಿ ಇತರರಿಗಿಂತ ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಹೊಂದಿರಬಹುದಾದ ಕ್ಷೇತ್ರಗಳು ಅಥವಾ ವ್ಯಕ್ತಿಗಳು ಅಥವಾ ತಂಡಗಳು ಇವೆಯೇ?
ಉದಾಹರಣೆ ಉತ್ತರ: ADR ನ ಆಡಳಿತವು ಈ ಆದ್ಯತೆಯ ಕ್ರಮದಲ್ಲಿದೆ: CEO, CTO, CLO, ADR ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ತಂಡ, AD ಬಗ್ಗೆ ಅತ್ಯಂತ ಹೆಚ್ಚು ತಿಳಿದಿರುವ ತಂಡದ ತಜ್ಞರು. ADR ನಲ್ಲಿ ವಿವರಿಸದ ಹೊರತು ಬೇರೆ ಯಾರಿಗೂ ಆಡಳಿತ ಅಧಿಕಾರವಿಲ್ಲ.
ಯಾವ ತತ್ವಗಳು ADR ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ?
ವೇಗವಾಗಿ ಚಲಿಸುವುದು ಮತ್ತು ನಿಧಾನವಾಗಿ ಚಲಿಸುವುದು, ನಿರ್ಧಾರ ಒಮ್ಮತ ಮತ್ತು ನಿರ್ಧಾರ ಸಂಘರ್ಷ, ಅಪಾಯ ಆದ್ಯತೆಗಳು ಮತ್ತು ಸುರಕ್ಷತೆ ಆದ್ಯತೆಗಳು, ಸಾರ್ವಜನಿಕ ಚರ್ಚೆ ಮತ್ತು ಖಾಸಗಿ ಚರ್ಚೆ ಮತ್ತು ಇಂತಹವುಗಳನ್ನು ಒಳಗೊಂಡ ನಿಮ್ಮ ಸಂಸ್ಥೆಯ ಕೆಲಸದ ವಿಧಾನಗಳಂತಹ ಕ್ಷೇತ್ರಗಳನ್ನು ಪರಿಗಣಿಸಿ.
ಉದಾಹರಣೆ ಉತ್ತರ: ನಾವು ಕ್ರಿಯೆಗೆ ಒಲವು, ಭಿನ್ನಾಭಿಪ್ರಾಯ ಇದ್ದರೂ ಬದ್ಧತೆ, ಸುಲಭವಾಗಿ ಹಿಂದಿರುಗಿಸಬಹುದಾದ ಮತ್ತು ಸುಲಭವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಬಹುದಾದ ನಿರ್ಧಾರಗಳಿಗೆ 70% ಅಂದಾಜುಗಳು ಸಾಕು, ಮತ್ತು ನಮ್ಮ ಸಂಸ್ಥೆಯ ಗೋಪ್ಯತಾ ಒಪ್ಪಂದದಲ್ಲಿ ವಿವರಿಸಿದಂತೆ ಗೋಪ್ಯ ಮಾಹಿತಿಯನ್ನು ಹೊರತುಪಡಿಸಿ ಸಾರ್ವಜನಿಕ ಕೆಲಸದ ವಿಧಾನಗಳು ಎಂಬ ನಾಯಕತ್ವ ತತ್ವಗಳನ್ನು ಬಳಸುತ್ತೇವೆ.
ADR ಗಾಗಿ ಮುಂದಿನ ಹಂತದ ಪರಿಕಲ್ಪನೆಗಳು
Arc42 ಎರಡು ಪ್ರಶ್ನೆಗಳಿಗೆ ವ್ಯಾವಹಾರಿಕ ಮತ್ತು ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಅಗತ್ಯಗಳಿಗೆ ಹೊಂದಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ. ನಿಮ್ಮ ವಾಸ್ತುಶಿಲ್ಪದ ಬಗ್ಗೆ ಏನನ್ನು ದಾಖಲಿಸಬೇಕು/ತಿಳಿಸಬೇಕು? ಅದನ್ನು ಹೇಗೆ ದಾಖಲಿಸಬೇಕು/ತಿಳಿಸಬೇಕು? Arc42 ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆಗಳನ್ನು ಮತ್ತು ಗುರಿಗಳು, ನಿರ್ಬಂಧಗಳು, ಸಂದರ್ಭ, ಗುಣಮಟ್ಟ, ಅಪಾಯಗಳು ಮತ್ತು ಇನ್ನಷ್ಟರ ಮಾರ್ಗದರ್ಶನವನ್ನು ಒಳಗೊಂಡಿದೆ.
C4 ಮಾದರಿ ತಂತ್ರಾಂಶ ವಾಸ್ತುಶಿಲ್ಪ ರೇಖಾಚಿತ್ರಗಳಿಗೆ ಕಲಿಯಲು ಸುಲಭ, ಡೆವಲಪರ್-ಸ್ನೇಹಿ ವಿಧಾನ. C4 ಎಂಬುದು ಸಂದರ್ಭ, ಕಂಟೇನರ್ಗಳು, ಘಟಕಗಳು, ಕೋಡ್ಗಾಗಿ ಶ್ರೇಣೀಕೃತ ರೇಖಾಚಿತ್ರಗಳ ಸಮೂಹ, ಜೊತೆಗೆ ವ್ಯವಸ್ಥೆ ಭೂದೃಶ್ಯ, ಡೈನಾಮಿಕ್ಸ್ ಮತ್ತು ನಿಯೋಜನೆಗೆ ಬೆಂಬಲ ರೇಖಾಚಿತ್ರಗಳು.
ವಾಸ್ತುಶಿಲ್ಪ ರೇಖಾಚಿತ್ರಗಳು, ನೋಟಗಳು ಮತ್ತು ದೃಷ್ಟಿಕೋನಗಳು
ವಾಸ್ತುಶಿಲ್ಪ ರೇಖಾಚಿತ್ರಗಳನ್ನು "ವಾಸ್ತುಶಿಲ್ಪ ನೋಟಗಳು" (architecture views) ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ.
"ವಾಸ್ತುಶಿಲ್ಪ ನೋಟ" ಎಂಬುದು "ವಾಸ್ತುಶಿಲ್ಪ ದೃಷ್ಟಿಕೋನ" (architecture viewpoint) ದ ಒಂದು ಉದಾಹರಣೆ.
"ವಾಸ್ತುಶಿಲ್ಪ ದೃಷ್ಟಿಕೋನ" ನಿರ್ದಿಷ್ಟ ಕಾಳಜಿಗಳನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡ ನಿರ್ದಿಷ್ಟ ಪ್ರೇಕ್ಷಕರನ್ನು ಹೊಂದಿದೆ.
ವಾಸ್ತುಶಿಲ್ಪ ದೃಷ್ಟಿಕೋನಗಳ ಉದಾಹರಣೆಗಳು, ಉದಾಹರಣೆ ನೋಟಗಳು ಮತ್ತು ಉದಾಹರಣೆ ರೇಖಾಚಿತ್ರಗಳು:
ವ್ಯಾಪಾರ ಸಾಮರ್ಥ್ಯಗಳು
ಉನ್ನತ ಮಟ್ಟದ ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳು
ಅಪ್ಲಿಕೇಶನ್ ಘಟಕಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಿದ ತಂತ್ರಾಂಶ ಕಾರ್ಯಗಳು
C4 ಮಾದರಿ ಸಂದರ್ಭ ರೇಖಾಚಿತ್ರ (TO-BE / AS-IS)
C4 ಮಾದರಿ ಕಂಟೇನರ್ ರೇಖಾಚಿತ್ರ (TO-BE / AS-IS)
ಡೇಟಾ ಘಟಕಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಘಟಕಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಲು ಘಟಕ ಸಂಬಂಧ ರೇಖಾಚಿತ್ರ (ERD)
ವ್ಯವಸ್ಥೆಯೊಳಗಿನ ಕಾರ್ಯಾತ್ಮಕ ಹರಿವುಗಳನ್ನು ಮತ್ತು ಏಕೀಕರಣಕ್ಕಾಗಿ ವಿವರಿಸಲು ಅನುಕ್ರಮ ರೇಖಾಚಿತ್ರ
ಅಪ್ಲಿಕೇಶನ್ ಘಟಕಗಳಾದ್ಯಂತ ಡೇಟಾ ಹರಿವುಗಳನ್ನು ವಿವರಿಸಲು Business Process Model and Notation (BPMN) ರೇಖಾಚಿತ್ರಗಳು
ವ್ಯಾಪಾರ ಪ್ರಕ್ರಿಯೆಗಳು / ಬಳಕೆದಾರ ಸನ್ನಿವೇಶಗಳನ್ನು ವಿವರಿಸಲು Business Process Model and Notation (BPMN) ರೇಖಾಚಿತ್ರಗಳು
ಗುರುತು ಮತ್ತು ಪ್ರವೇಶ ನಿರ್ವಹಣೆ (IAM) ರೇಖಾಚಿತ್ರಗಳು
ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಘಟಕಕ್ಕೆ ಪಾತ್ರಗಳೊಂದಿಗೆ ಪಾತ್ರ-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ (RBAC) ರೇಖಾಚಿತ್ರಗಳು
ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಘಟಕಕ್ಕೆ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಗುಣಲಕ್ಷಣ-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ (ABAC) ರೇಖಾಚಿತ್ರಗಳು
ಗೌಪ್ಯತೆ ರೇಖಾಚಿತ್ರಗಳು
ಸಂಬಂಧಿತ ರೇಖಾಚಿತ್ರಗಳು:
ಬಳಕೆಯ ಪ್ರಕರಣ ರೇಖಾಚಿತ್ರವು ನಿರ್ವಹಣೆ/ಗ್ರಾಹಕರಿಗೆ ಬಳಕೆಯ ಪ್ರಕರಣಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದು ಅವಶ್ಯಕತೆಗಳಿಗೆ ಮುಂಚಿತವಾಗಿರುತ್ತದೆ, ಅದು ತಂತ್ರಾಂಶ ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ ಮುಂಚಿತವಾಗಿರುತ್ತದೆ.
ನಿಯೋಜನೆ ರೇಖಾಚಿತ್ರವು ತಂತ್ರಾಂಶ ಘಟಕಗಳು ಇರುವ ಭೌತಿಕ ಹಾರ್ಡ್ವೇರ್/ಕಂಪ್ಯೂಟರ್ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.
ಡೇಟಾ ಹರಿವು ರೇಖಾಚಿತ್ರವು ಡೇಟಾ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ ಹೇಗೆ ಚಲಿಸಿ ರೂಪಾಂತರಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
HTTP ಯಂತಹ ಪ್ರೋಟೋಕಾಲ್ಗಳು ಸಮಯದ ಅಕ್ಷದ ಮೇಲೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ಅನುಕ್ರಮ ರೇಖಾಚಿತ್ರಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.
ಚಟುವಟಿಕೆ ರೇಖಾಚಿತ್ರವು AI NPC ಯಂತಹ ತಂತ್ರಾಂಶ ವ್ಯವಸ್ಥೆ ನಿರ್ವಹಿಸುವ ಚಟುವಟಿಕೆಗಳ ಕೆಲಸದ ಹರಿವನ್ನು ಚಿತ್ರಿಸುತ್ತದೆ.
ಕೋಡ್ ರೂಪದ ನಿರ್ಧಾರಗಳಿಗೆ ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು
ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು (fitness functions) ಎಂದರೆ ನಿರ್ಧಾರಗಳನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲಾಗುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವ, ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಕೋಡ್ನಿಂದ ಬರೆದ ವಸ್ತುನಿಷ್ಠ ಸ್ವಯಂಚಾಲಿತ ಪರಿಶೀಲನೆಗಳು.
ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ನಿರ್ಧಾರಗಳನ್ನು ಪರೀಕ್ಷಿಸಬಹುದಾದ ಮತ್ತು ಖಾತರಿಪಡಿಸಬಹುದಾದ ಸ್ವರೂಪಕ್ಕೆ ತರುತ್ತವೆ.
ನಿರ್ಧಾರಗಳಿಗಾಗಿ ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ಗುಣಮಟ್ಟ ಭರವಸೆ, ನಿಯಂತ್ರಕ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಆಡಳಿತ ಗುರಿಗಳಿಗೆ ಬಹಳ ನೆರವಾಗಬಲ್ಲವು.
ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ನಿರ್ಧಾರಗಳಿಗೆ ಹೇಗೆ ಸಂಪರ್ಕ ಹೊಂದಿವೆ
ನಿರ್ಧಾರ ದಾಖಲೆಯು ನಿರ್ಧಾರವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಆದರೆ ಸೂಕ್ತತಾ ಕಾರ್ಯವು ನಿರ್ಧಾರವನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ.
ಉದಾಹರಣೆ ನಿರ್ಧಾರ: ಲೆಕ್ಕಪರಿಶೋಧನೆ ಅವಶ್ಯಕತೆಗಳಿಗಾಗಿ ನಾವು ಈವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ಬಳಸುತ್ತೇವೆ.
ಉದಾಹರಣೆ ಸೂಕ್ತತಾ ಕಾರ್ಯ: ಎಲ್ಲಾ ಸ್ಥಿತಿ ಬದಲಾವಣೆಗಳು ಈವೆಂಟ್ಗಳನ್ನು ಉತ್ಪಾದಿಸಬೇಕು ಎಂದು ಪರೀಕ್ಷಿಸಲು ನಾವು ನಿರಂತರ ಏಕೀಕರಣ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.
ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ನಿರ್ಧಾರಗಳಿಗೆ ಏಕೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ
ವಸ್ತುನಿಷ್ಠ ಅಳತೆಗಳು: ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ಪಾಸ್ ಅಥವಾ ಫೇಲ್ ಆಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಗೋಚರವಾಗಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಇರುತ್ತದೆ.
ನಿರಂತರ ಬಳಕೆ: ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ನಿಮ್ಮ ಜೀವಂತ ನಿಯಮಗಳು; ಪ್ರತಿ ಕಮಿಟ್ ಮತ್ತು ಬಿಲ್ಡ್ನಲ್ಲಿ ಅವು ಚಾಲನೆಯಾಗುತ್ತವೆ.
ಮರುರಚನೆಯ ವಿಶ್ವಾಸ: ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ನಿರ್ಧಾರ ನಿಯಮದ ದೋಷಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹಿಡಿಯುತ್ತವೆ.
ವಿಸ್ತರಿಸಬಹುದಾದ ಆಡಳಿತ: ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ಅಡಚಣೆಗಳನ್ನು ಸೃಷ್ಟಿಸದೆ ಮಾನದಂಡಗಳನ್ನು ಖಾತರಿಪಡಿಸುತ್ತವೆ.
ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು AI ಬಳಸಬಹುದೇ?
ಸೂಕ್ತತಾ ಕಾರ್ಯಗಳು ನಿಮ್ಮ ಯೋಜನೆಗಳು, ಕೋಡ್, ಸ್ಕೀಮಾಗಳು, API ಗಳು ಮತ್ತು ಇನ್ನಷ್ಟು ನಿಮ್ಮ ಕೆಲಸದ ಬಗ್ಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುವ ಮೂಲಕ ನಿರ್ಧಾರಗಳಿಗಾಗಿ AI LLM ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು:
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.
ವಾಸ್ತುಶಿಲ್ಪ ಯೂನಿಟ್ ಪರೀಕ್ಷೆ
ArchUnit: ಯಾವುದೇ ಸರಳ Java ಯೂನಿಟ್ ಪರೀಕ್ಷಾ ಚೌಕಟ್ಟನ್ನು ಬಳಸಿ Java ಕೋಡ್ನ ವಾಸ್ತುಶಿಲ್ಪ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ArchUnitTS: Jest, Vitest, Jasmine ಇತ್ಯಾದಿಗಳನ್ನು ಬಳಸಿ TypeScript ಕೋಡ್ ಮತ್ತು JavaScript ಕೋಡ್ನ ವಾಸ್ತುಶಿಲ್ಪ ನಿಯಮಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ ಬಳಕೆಗೆ ನಿರ್ಧಾರ ರಕ್ಷಕಗಳು
Decision Guardian ಸರಿಯಾದ ನಿರ್ಧಾರ ದಾಖಲೆಗಳನ್ನು ಸರಿಯಾದ ಕ್ಷಣದಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮೇಲ್ಮೈಗೆ ತರುತ್ತದೆ — ಅಂದರೆ ಡೆವಲಪರ್ ಆ ನಿರ್ಧಾರದಿಂದ ರಕ್ಷಿತ ಕೋಡ್ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬದಲಾಯಿಸುತ್ತಿರುವಾಗ. ವಿಲೀನಗೊಳಿಸುವ ಮೊದಲು ಡೆವಲಪರ್ಗಳು ದಾಖಲೆಗಳ ಫೋಲ್ಡರ್ ಓದುತ್ತಾರೆ ಎಂದು ಆಶಿಸುವ ಬದಲು, ಸಂಬಂಧಿತ ಸಂದರ್ಭ ನೇರವಾಗಿ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ನಲ್ಲೇ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಇದು ಯಾವುದೇ ರೀತಿಯ ನಿರ್ಧಾರ ದಾಖಲೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರಗಳು, ಡೇಟಾ ನಿರ್ಧಾರಗಳು, ಅನುಸರಣೆ ನಿರ್ಧಾರಗಳು, ವೈದ್ಯಕೀಯ ಮತ್ತು ಆರೋಗ್ಯ ನಿರ್ಧಾರಗಳು, ಭದ್ರತಾ ನಿರ್ಧಾರಗಳು, ಮತ್ತು ಇನ್ನಷ್ಟು.
ಯಾವುದೇ CI ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ (GitLab, Jenkins, CircleCI) ಮತ್ತು ಪ್ರಿ-ಕಮಿಟ್ ಹುಕ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಮುಕ್ತ ಮೂಲ. MIT ಪರವಾನಗಿ.
ADR Guard ಎಂಬುದು ವೀಕ್ಷಿಸಲಾದ ಕೋಡ್
ಮಾರ್ಗಗಳು ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ ದಾಖಲೆಯನ್ನು ಸೇರಿಸದೆ ಅಥವಾ ನವೀಕರಿಸದೆ ಬದಲಾದಾಗ ಪುಲ್
ರಿಕ್ವೆಸ್ಟ್ ಅನ್ನು ವಿಫಲಗೊಳಿಸುವ GitHub Action. ವಿನಾಯಿತಿಗಳು ಸ್ಪಷ್ಟ: ಕಾರಣದೊಂದಿಗೆ
ADR-Exempt: ಸಾಲು ಗೇಟ್ ಅನ್ನು ಹಾದುಹೋಗುತ್ತದೆ ಮತ್ತು ಕೆಲಸದ ಸಾರಾಂಶಕ್ಕೆ ಬರೆಯಲ್ಪಡುತ್ತದೆ.
ಟೆಂಪ್ಲೇಟು-ತಟಸ್ಥ, ಯಾವುದೇ ಅವಲಂಬನೆಗಳಿಲ್ಲ. ಮುಕ್ತ ಮೂಲ. MIT ಪರವಾನಗಿ.
ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ
ಪರಿಚಯ:
ಟೆಂಪ್ಲೇಟುಗಳು:
Documenting architecture decisions - Michael Nygard (thinkrelevance.com)
Template for documenting architecture alternatives and decisions (stackoverflow.com)
ಆಳವಾದ ಅಧ್ಯಯನ:
The Decision View's Role in Software Architecture Practice (computer.org)
Documenting Software Architectures: Views and Beyond (resources.sei.cmu.edu)
Architecture Decisions: Demystifying Architecture (utdallas.edu)
ThoughtWorks Technology Radar: Lightweight Architecture Decision Records (thoughtworks.com)
A Skeptic’s Guide to Software Architecture Decisions (infoq.com)
Architectural Retrospectives: the Key to Getting Better at Architecting
Software Architecture Monday with Mark Richards — ಮಾಸಿಕ ಉಚಿತ ತಂತ್ರಾಂಶ ವಾಸ್ತುಶಿಲ್ಪ ಪಾಠ
"Keep the Why: Code Becomes Legacy When Nobody Remembers Why"
ಸಾಧನಗಳು:
Command-line tools for working with Architecture Decision Records
kgai - append-only decision log for AI coding agents, a machine-readable companion to ADR files
ಕಂಪನಿ-ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗದರ್ಶನ:
ಉದಾಹರಣೆಗಳು:
ವೀಡಿಯೊಗಳು:
ಪಾಡ್ಕಾಸ್ಟ್ಗಳು:
ಪುಸ್ತಕಗಳು:
Software Architecture in Practice (SEI Series in Software Engineering)
Documenting Software Architectures: Views and Beyond (SEI Series in Software Engineering)
The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise
Fundamentals of Software Architecture: An Engineering Approach - by Mark Richards and Neal Ford
Building Evolutionary Architectures - by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage
Foundations of Decision Analysis by Ronald Howard and Ali Abbas
Head First Software Architecture - by Raju Gandhi, Neal Ford and Mark Richards
Communication Patterns: A Guide for Developers and Architects - by Jacqui Read
ಇದನ್ನೂ ನೋಡಿ:
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) — ಸ್ಪಷ್ಟ ತರ್ಕ, ಊಹೆಗಳು, ಅರಿವಿನ ಸ್ಥಿತಿ ಮತ್ತು ಸಾಧಕ-ಬಾಧಕ ಹೊಂದಾಣಿಕೆಗಳೊಂದಿಗೆ ನಿರ್ಧಾರಗಳನ್ನು ಪ್ರತಿನಿಧಿಸಲು ಮಾರಾಟಗಾರ-ತಟಸ್ಥ, ಯಂತ್ರ-ಓದಬಲ್ಲ YAML/JSON ಸ್ವರೂಪ. ನಿರ್ಧಾರ ದಾಖಲಾತಿಗೆ ರಚನಾತ್ಮಕ, ಮೌಲ್ಯೀಕರಿಸಬಹುದಾದ ತರ್ಕವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ADR ಗಳಿಗೆ ಪೂರಕವಾಗಿದೆ.