Architecture Decision Record

கட்டமைப்பு முடிவு பதிவு (ADR)

கட்டமைப்பு முடிவுகளைப் பதிவு செய்வதற்கான வார்ப்புருக்கள், எடுத்துக்காட்டுகள், வழிகாட்டிகள்.

கட்டமைப்பு முடிவு பதிவு (ADR) என்பது எடுக்கப்பட்ட ஒரு முக்கியமான கட்டமைப்பு முடிவை அதன் சூழலுடனும் விளைவுகளுடனும் பதிவு செய்யும் ஆவணம்.

மொழிபெயர்ப்புகள்: العربية, বাংলা, Cymraeg, Dansk, Deutsch, English, Lietuvių, Gaeilge, Lëtzebuergesch, தமிழ், मराठी, Hausa, ગુજરાતી, Euskara, भोजपुरी, Basa Jawa, فارسی, ਪੰਜਾਬੀ, 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) என்பது எடுக்கப்பட்ட ஒரு முக்கியமான கட்டமைப்பு முடிவை அதன் சூழலுடனும் விளைவுகளுடனும் பதிவு செய்யும் ஆவணம்.

கட்டமைப்பு முடிவு (AD) என்பது ஒரு குறிப்பிடத்தக்க தேவையை நிறைவேற்றும் மென்பொருள் வடிவமைப்புத் தேர்வு.

கட்டமைப்பு முடிவுப் பேரேடு (ADL) என்பது ஒரு குறிப்பிட்ட திட்டத்திற்காக (அல்லது நிறுவனத்திற்காக) உருவாக்கப்பட்டுப் பராமரிக்கப்படும் அனைத்து ADR களின் தொகுப்பு.

கட்டமைப்பு ரீதியாக முக்கியமான தேவை (ASR) என்பது ஒரு மென்பொருள் அமைப்பின் கட்டமைப்பில் அளவிடக்கூடிய தாக்கத்தை ஏற்படுத்தும் தேவை.

இவை அனைத்தும் கட்டமைப்பு அறிவு மேலாண்மை (AKM) என்ற தலைப்பின் கீழ் வருகின்றன.

ADR களைப் பற்றிய விரைவான மேலோட்டத்தையும், அவற்றை எவ்வாறு உருவாக்குவது என்பதையும், மேலும் தகவலுக்கு எங்கே பார்ப்பது என்பதையும் வழங்குவதே இந்த ஆவணத்தின் நோக்கம்.

சுருக்கங்கள்:

  • AD: கட்டமைப்பு முடிவு

  • ADL: கட்டமைப்பு முடிவுப் பேரேடு

  • ADR: கட்டமைப்பு முடிவு பதிவு

  • AKM: கட்டமைப்பு அறிவு மேலாண்மை

  • ASR: கட்டமைப்பு ரீதியாக முக்கியமான தேவை

ADR பயன்பாட்டைத் தொடங்குவது எப்படி

ADR களைப் பயன்படுத்தத் தொடங்க, உங்கள் குழுத் தோழர்களுடன் இந்தப் பகுதிகளைப் பற்றிப் பேசுங்கள்.

முடிவைக் கண்டறிதல்:

  • AD எவ்வளவு அவசரமானது, எவ்வளவு முக்கியமானது?

  • இதை இப்போதே எடுக்க வேண்டுமா, அல்லது மேலும் தெரியவரும் வரை காத்திருக்கலாமா?

  • தனிப்பட்ட மற்றும் கூட்டு அனுபவம், அத்துடன் அங்கீகரிக்கப்பட்ட வடிவமைப்பு முறைகளும் நடைமுறைகளும், முடிவைக் கண்டறிய உதவும்.

  • சிறந்த முறையில், தயாரிப்புச் செய்ய-வேண்டியவை பட்டியலை நிறைவுசெய்யும் முடிவுகளுக்கான செய்ய-வேண்டியவை பட்டியலைப் பராமரிக்கவும்.

முடிவெடுத்தல்:

  • பொதுவானவை, மென்பொருள் கட்டமைப்புக்கே உரியவை (எ.கா. உரையாடல் வரைபடமாக்கல்) என பல முடிவெடுக்கும் நுட்பங்கள் உள்ளன.

  • குழு முடிவெடுத்தல் ஒரு செயலில் உள்ள ஆராய்ச்சித் தலைப்பு.

முடிவை நடைமுறைப்படுத்துதலும் கடைப்பிடித்தலும்:

  • AD கள் மென்பொருள் வடிவமைப்பில் பயன்படுத்தப்படுகின்றன; எனவே அமைப்புக்கு நிதியளிக்கும், உருவாக்கும், இயக்கும் பங்குதாரர்களுக்கு அவை தெரிவிக்கப்பட்டு, அவர்களால் ஏற்கப்பட வேண்டும்.

  • கட்டமைப்பு வெளிப்படையாகத் தெரியும் குறியீட்டு நடை மற்றும் கட்டமைப்புக் கவலைகள், முடிவுகளில் கவனம் செலுத்தும் குறியீட்டு மதிப்பாய்வுகள் ஆகியவை இரண்டு தொடர்புடைய நடைமுறைகள்.

  • மென்பொருள் பரிணாமத்தில் ஒரு மென்பொருள் அமைப்பை நவீனப்படுத்தும்போதும் AD கள் (மீண்டும்) பரிசீலிக்கப்பட வேண்டும்.

முடிவைப் பகிர்தல் (விருப்பத்தேர்வு):

  • பல AD கள் திட்டங்கள் முழுவதும் மீண்டும் மீண்டும் வருகின்றன.

  • எனவே, வெளிப்படையான அறிவு மேலாண்மை உத்தியைப் பின்பற்றும்போது, கடந்த கால முடிவுகளின் நல்ல, கெட்ட அனுபவங்கள் மதிப்புமிக்க மறுபயன்பாட்டுச் சொத்துகளாக இருக்கலாம்.

முடிவை ஆவணப்படுத்துதல்:

  • முடிவுகளைப் பதிவு செய்ய பல வார்ப்புருக்களும் கருவிகளும் உள்ளன.

  • சுறுசுறுப்பான (agile) சமூகங்களைப் பாருங்கள், எ.கா. M. Nygard இன் ADR கள்.

  • பாரம்பரிய மென்பொருள் பொறியியல் மற்றும் கட்டமைப்பு வடிவமைப்புச் செயல்முறைகளைப் பாருங்கள், எ.கா. IBM UMF மற்றும் CapitalOne இன் Tyree, Akerman பரிந்துரைத்த அட்டவணை அமைப்புகள்.

மேலும்:

  • மேலே உள்ள படிகள் Architectural Decision என்ற Wikipedia பதிவிலிருந்து எடுக்கப்பட்டவை

கருவிகளுடன் ADR பயன்பாட்டைத் தொடங்குவது எப்படி

  • MySpec — திட்ட அரசியலமைப்பு, தொழில்நுட்பக் கட்டமைப்பு, ADR களைத் தூய்மையான Markdown ஆக ஒழுங்குபடுத்தி MCP வழியாக வழங்கும் தானியங்கு விவரக்குறிப்பு மற்றும் கட்டமைப்பு முடிவுத் தளம்.

கருவிகளுடன் 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 களஞ்சியத்தில் commit செய்யுங்கள்.

ADR க்கான Claude Code திறன்கள்

இந்தக் களஞ்சியம் skills/ கீழ் இரண்டு Claude Code திறன்களை வழங்குகிறது, இதனால் 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

எங்கள் கோப்பு பெயர் மரபு:

  • பெயரில் நிகழ்காலக் கட்டளை வினைத்தொடர் இருக்கும். இது படிக்க எளிதாக்குவதோடு எங்கள் commit செய்தி வடிவத்துடனும் பொருந்துகிறது.

  • பெயர் சிறிய எழுத்துகளையும் இடைக்கோடுகளையும் (dashes) பயன்படுத்துகிறது (இந்தக் களஞ்சியத்தைப் போல). இது படிக்கும் தன்மைக்கும் அமைப்புப் பயன்பாட்டுக்கும் இடையிலான சமநிலை.

  • நீட்டிப்பு markdown. எளிதான வடிவமைப்புக்கு இது பயனுள்ளதாக இருக்கலாம்.

நல்ல ADR எழுதுவதற்கான பரிந்துரைகள்

நல்ல ADR இன் பண்புகள்:

  • நியாயம்: குறிப்பிட்ட AD ஐ ஏன் செய்தீர்கள் என்பதற்கான காரணங்களை விளக்குங்கள். இதில் சூழல் (கீழே பார்க்க), சாத்தியமான பல்வேறு தேர்வுகளின் நன்மை தீமைகள், அம்ச ஒப்பீடுகள், செலவு/பலன் விவாதங்கள் மற்றும் பல அடங்கும்.

  • குறிப்பிட்டது: ஒவ்வொரு ADR உம் ஒரு AD பற்றியதாக இருக்க வேண்டும், பல AD கள் பற்றியதாக அல்ல.

  • நேரமுத்திரைகள்: ADR இல் உள்ள ஒவ்வொரு பொருளும் எப்போது எழுதப்பட்டது என்பதைக் குறிப்பிடுங்கள். செலவுகள், அட்டவணைகள், அளவிடுதல் போன்ற காலப்போக்கில் மாறக்கூடிய அம்சங்களுக்கு இது குறிப்பாக முக்கியம்.

  • மாற்ற இயலாதது: ADR இல் உள்ள தகவலை மாற்றாதீர்கள். மாறாக, புதிய தகவலைச் சேர்த்து ADR ஐத் திருத்துங்கள், அல்லது புதிய ADR ஐ உருவாக்கி அதை மாற்றியமையுங்கள்.

ADR இல் உள்ள நல்ல "சூழல்" பகுதியின் பண்புகள்:

  • உங்கள் நிறுவனத்தின் நிலைமையையும் வணிக முன்னுரிமைகளையும் விளக்குங்கள்.

  • உங்கள் குழுக்களின் சமூக மற்றும் திறன் அமைப்பின் அடிப்படையிலான நியாயங்களையும் பரிசீலனைகளையும் சேர்க்கவும்.

  • பொருத்தமான நன்மை தீமைகளைச் சேர்த்து, உங்கள் தேவைகள் மற்றும் இலக்குகளுடன் ஒத்துப்போகும் சொற்களில் அவற்றை விவரியுங்கள்.

ADR இல் உள்ள நல்ல "விளைவுகள்" பகுதியின் பண்புகள்:

  • முடிவெடுத்ததன் தொடர்ச்சியாக என்ன நடக்கிறது என்பதை விளக்குங்கள். இதில் தாக்கங்கள், விளைவுகள், வெளியீடுகள், தொடர்நடவடிக்கைகள் மற்றும் பல அடங்கலாம்.

  • அடுத்தடுத்த ADR கள் பற்றிய தகவலைச் சேர்க்கவும். ஒரு ADR பெரிய, பரந்த தேர்வைச் செய்து அது மேலும் சிறிய முடிவுகளுக்கான தேவைகளை உருவாக்கும்போது போல, ஒரு ADR மேலும் ADR களின் தேவையைத் தூண்டுவது ஒப்பீட்டளவில் பொதுவானது.

  • செயலுக்குப் பிந்தைய மதிப்பாய்வுச் செயல்முறைகளைச் சேர்க்கவும். கற்றுக்கொண்டு வளர்வதற்காக, ADR தகவலை நடைமுறையில் நடந்ததுடன் ஒப்பிட்டு, ஒவ்வொரு ADR ஐயும் ஒரு மாதம் கழித்துக் குழுக்கள் மதிப்பாய்வு செய்வது வழக்கம்.

புதிய ADR முந்தைய ADR இன் இடத்தைப் பிடிக்கலாம்:

  • முந்தைய ADR ஐ மாற்றியமைக்கும் அல்லது செல்லாததாக்கும் AD எடுக்கப்படும்போது, புதிய ADR உருவாக்கப்பட வேண்டும்

ADR எடுத்துக்காட்டு வார்ப்புருக்கள்

இணையத்திலிருந்து நாங்கள் சேகரித்த ADR எடுத்துக்காட்டு வார்ப்புருக்கள்:

ADR க்கான குழுப்பணி ஆலோசனை

உங்கள் குழுவுடன் முடிவுப் பதிவுகளைப் பயன்படுத்த நினைத்தால், பல குழுக்களுடன் பணியாற்றியதன் மூலம் நாங்கள் கற்றுக்கொண்ட சில ஆலோசனைகள் இங்கே.

"என்ன" என்பதைக் கட்டாயப்படுத்துவதற்குப் பதிலாக, "ஏன்" என்பதைப் பற்றி ஒன்றாகப் பேசுவதன் மூலம் உங்கள் குழுத் தோழர்களை வழிநடத்த உங்களுக்கு வாய்ப்பு உள்ளது. எடுத்துக்காட்டாக, முடிவுப் பதிவுகள் குழுக்கள் புத்திசாலித்தனமாகச் சிந்திக்கவும் சிறப்பாகத் தொடர்புகொள்ளவும் உதவும் வழி; நடந்து முடிந்த பிறகு கட்டாயமாகத் திணிக்கப்படும் காகிதப்பணித் தேவையாக மட்டும் இருந்தால் முடிவுப் பதிவுகளுக்கு மதிப்பில்லை.

சில குழுக்கள் "ADR" என்ற சுருக்கத்தை விட "முடிவுகள்" என்ற பெயரையே மிகவும் விரும்புகின்றன. சில குழுக்கள் "decisions" என்ற கோப்பகப் பெயரைப் பயன்படுத்தும்போது, விளக்கு எரிவது போன்றிருக்கிறது; குழு அந்தக் கோப்பகத்தில் விற்பனையாளர் முடிவுகள், திட்டமிடல் முடிவுகள், அட்டவணை முடிவுகள் போன்ற மேலும் தகவல்களை வைக்கத் தொடங்குகிறது. இந்த எல்லா வகைத் தகவலுக்கும் ஒரே வார்ப்புருவைப் பயன்படுத்தலாம். சுருக்கங்களை ("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 இன் நிர்வாகம் இந்த முன்னுரிமை வரிசையில் உள்ளது: CEO, CTO, CLO, ADR ஐ நடைமுறைப்படுத்தும் குழு, AD பற்றி அதிகம் அறிந்த குழுவில் உள்ள நிபுணர்கள். ADR இல் விவரிக்கப்பட்டாலன்றி வேறு யாருக்கும் நிர்வாகம் இல்லை.

எந்தக் கொள்கைகள் ADR உடன் தொடர்புடையவை?

வேகமாக நகர்தல் மற்றும் மெதுவாக நகர்தல், முடிவு ஒருமித்த கருத்து மற்றும் முடிவு மோதல், ஆபத்து விருப்பங்கள் மற்றும் பாதுகாப்பு விருப்பங்கள், பொது விவாதம் மற்றும் தனிப்பட்ட விவாதம் போன்றவற்றை உள்ளடக்கிய உங்கள் நிறுவனத்தின் வேலை முறைகள் போன்ற பகுதிகளைப் பரிசீலியுங்கள்.

எடுத்துக்காட்டுப் பதில்: செயலுக்கான சாய்வு, உடன்படாமல்-ஆனால்-உறுதியளி, எளிதில் மாற்றக்கூடிய, எளிதில் தனிமைப்படுத்தக்கூடிய முடிவுகளுக்கு 70% மதிப்பீடுகள் போதுமானவை ஆகிய தலைமைக் கொள்கைகளையும், எங்கள் நிறுவனத்தின் ரகசிய ஒப்பந்தத்தில் விவரிக்கப்பட்டுள்ள ரகசியத் தகவல் தவிர பொது வேலை முறைகளையும் பயன்படுத்துகிறோம்.

ADR க்கான அடுத்தநிலைக் கருத்துகள்

Arc42 இரண்டு கேள்விகளுக்கு நடைமுறை ரீதியாகப் பதிலளிக்கிறது, உங்கள் குறிப்பிட்ட தேவைகளுக்கு ஏற்ப தகவமைக்கலாம். உங்கள் கட்டமைப்பைப் பற்றி எதை ஆவணப்படுத்த/தெரிவிக்க வேண்டும்? எப்படி ஆவணப்படுத்த/தெரிவிக்க வேண்டும்? Arc42 இல் கட்டமைப்பு முடிவு பதிவுக்கு மேலதிகமாக இலக்குகள், கட்டுப்பாடுகள், சூழல்கள், தரம், ஆபத்துகள் மற்றும் பலவற்றுக்கான வழிகாட்டுதல் அடங்கும்.

C4 மாதிரி என்பது மென்பொருள் கட்டமைப்பு வரைபடங்களுக்கான கற்க எளிதான, உருவாக்குநர்-நட்பு அணுகுமுறை. C4 என்பது சூழல், கொள்கலன்கள், கூறுகள், குறியீடுக்கான படிநிலை வரைபடங்களின் தொகுப்பு, அத்துடன் அமைப்புச் சூழல்காட்சி, இயங்குநிலை, வரிசைப்படுத்தலுக்கான துணை வரைபடங்கள்.

கட்டமைப்பு வரைபடங்கள், காட்சிகள், பார்வைகள்

கட்டமைப்பு வரைபடம் "கட்டமைப்புக் காட்சி" என்று அழைக்கப்படுகிறது.

"கட்டமைப்புக் காட்சி" என்பது "கட்டமைப்புப் பார்வைக்கு" ஓர் எடுத்துக்காட்டு.

"கட்டமைப்புப் பார்வைக்கு" குறிப்பிட்ட கவலைகளை மனதில் கொண்ட குறிப்பிட்ட பார்வையாளர்கள் உண்டு.

கட்டமைப்புப் பார்வைகளின் எடுத்துக்காட்டுகள், காட்சிகளின் எடுத்துக்காட்டுகள், வரைபடங்களின் எடுத்துக்காட்டுகள்:

தொடர்புடைய வரைபடங்கள்:

  • பயன்பாட்டு நிகழ்வு வரைபடம் (Use Case Diagram) மேலாண்மை/வாடிக்கையாளர்களுக்குப் பயன்பாட்டு நிகழ்வுகளைக் காட்டுகிறது, அவை தேவைகளுக்கு முந்தையவை, அவை மென்பொருள் கட்டமைப்புக்கு முந்தையவை.

  • வரிசைப்படுத்தல் வரைபடம் (Deployment Diagram) மென்பொருள் கூறுகள் வரிசைப்படுத்தப்படும் இயற்பியல் வன்பொருள்/கணினிகளைக் காட்டுகிறது.

  • தரவு ஓட்ட வரைபடம் (Data Flow Diagram) தரவு அமைப்பு வழியாக எவ்வாறு நகர்கிறது, மாற்றப்படுகிறது என்பதைக் காட்டுகிறது.

  • வரிசை வரைபடம் (Sequence Diagram) HTTP போன்ற நெறிமுறைகள் காலக் கோட்டில் எவ்வாறு செயல்படுகின்றன என்பதைக் காட்டப் பயன்படுகிறது.

  • செயல்பாட்டு வரைபடம் (Activity Diagram) NPC AI போன்ற மென்பொருள் அமைப்பு நிகழ்த்தும் செயல்பாடுகளின் பணிப்பாய்வைக் காட்டுகிறது.

குறியீடாக முடிவுகளுக்கான தகுதிச் செயல்பாடுகள்

தகுதிச் செயல்பாடுகள் (fitness functions) என்பவை நிரலாக்கக் குறியீட்டால் எழுதப்பட்ட, முடிவுகள் பேணப்படுகின்றனவா என்பதைச் சரிபார்க்கும் புறநிலைத் தானியங்கிச் சோதனைகள்.

  • தகுதிச் செயல்பாடுகள் முடிவுகளைச் சோதிக்கக்கூடியவையாகவும் உறுதிப்படுத்தக்கூடியவையாகவும் ஆக்குகின்றன.

  • முடிவுகளுக்கான தகுதிச் செயல்பாடுகள் தர உறுதி, ஒழுங்குமுறைச் செயல்முறைகள், நிர்வாக இலக்குகளுக்கு பெரிதும் உதவும்.

தகுதிச் செயல்பாடுகள் முடிவுகளுடன் எவ்வாறு இணைகின்றன

முடிவுப் பதிவு முடிவை ஆவணப்படுத்துகிறது, தகுதிச் செயல்பாடு முடிவை உறுதிப்படுத்துகிறது.

  • எடுத்துக்காட்டு முடிவு: தணிக்கைத் தேவைகளுக்காக நாங்கள் event sourcing ஐப் பயன்படுத்துகிறோம்.

  • எடுத்துக்காட்டுத் தகுதிச் செயல்பாடு: அனைத்து நிலை மாற்றங்களும் நிகழ்வுகளை உருவாக்க வேண்டும் என்பதைச் சோதிக்கத் தொடர்ச்சியான ஒருங்கிணைப்புச் சேவையகத்தைப் பயன்படுத்துகிறோம்.

தகுதிச் செயல்பாடுகள் முடிவுகளுக்கு ஏன் உதவுகின்றன

புறநிலை அளவீடுகள்: தகுதிச் செயல்பாடுகள் தேர்ச்சி அல்லது தோல்வி அடைகின்றன, எனவே வேலை புலப்படும்படியும் தெளிவாகவும் உள்ளது.

தொடர்ச்சியான பயன்பாடு: தகுதிச் செயல்பாடுகள் உங்கள் உயிருள்ள விதிகள், ஒவ்வொரு commit மற்றும் build இலும் இயக்கப்படுகின்றன.

மறுசீரமைக்கும் நம்பிக்கை: தகுதிச் செயல்பாடுகள் முடிவு விதிப் பிழைகளைத் தானாகவே பிடிக்கின்றன.

அளவிடக்கூடிய நிர்வாகம்: தகுதிச் செயல்பாடுகள் தடைகளை உருவாக்காமல் தரநிலைகளை உறுதிப்படுத்துகின்றன.

தகுதிச் செயல்பாடுகள் 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) pre-commit hook ஆகவும் வேலை செய்கிறது. திறந்த மூலம். MIT உரிமம்.

ADR Guard ஒரு GitHub Action ஆகும், கண்காணிக்கப்படும் குறியீட்டுப் பாதை மாறி, கட்டமைப்பு முடிவுப் பதிவு சேர்க்கப்படாதபோது அல்லது புதுப்பிக்கப்படாதபோது இழுப்புக் கோரிக்கையைத் தோல்வியடையச் செய்கிறது. விலக்குகள் வெளிப்படையானவை: காரணத்துடன் கூடிய ADR-Exempt: வரி வாயிலைக் கடக்க அனுமதித்து, பணி சுருக்கத்தில் பதிவு செய்யப்படுகிறது. வார்ப்புரு-சார்பற்றது, சார்புகள் இல்லை. திறந்த மூலம். MIT உரிமம்.

மேலும் தகவலுக்கு

அறிமுகம்:

வார்ப்புருக்கள்:

ஆழமாக:

கருவிகள்:

நிறுவனம்-சார்ந்த வழிகாட்டுதல்:

எடுத்துக்காட்டுகள்:

காணொளிகள்:

பாட்காஸ்ட்கள்:

புத்தகங்கள்:

மேலும் பார்க்க:

  • 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 களுக்குத் துணைபுரிகிறது.