Architecture Decision Record

Active theme: Light

← ឯកសារ

ដំណើរការកំណត់ត្រាការសម្រេចចិត្តខាងស្ថាបត្យកម្មរបស់ AWS

https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html

កំណត់ត្រាការសម្រេចចិត្តខាងស្ថាបត្យកម្ម (ADR) គឺជាឯកសារដែលពិពណ៌នាអំពីជម្រើសមួយដែលក្រុមធ្វើឡើងអំពីទិដ្ឋភាពដ៏សំខាន់នៃស្ថាបត្យកម្មកម្មវិធីដែលពួកគេគ្រោងនឹងកសាង។ ADR នីមួយៗពិពណ៌នាអំពីការសម្រេចចិត្តខាងស្ថាបត្យកម្ម បរិបទ និងផលវិបាករបស់វា។ ADR មានស្ថានភាព ហេតុនេះវាអនុវត្តតាមវដ្តជីវិតមួយ។ សម្រាប់ឧទាហរណ៍នៃ ADR សូមមើលឧបសម្ព័ន្ធ។

ដំណើរការ ADR បង្កើតលទ្ធផលជាបណ្តុំនៃកំណត់ត្រាការសម្រេចចិត្តខាងស្ថាបត្យកម្ម។ បណ្តុំនេះបង្កើតជាកំណត់ហេតុការសម្រេចចិត្ត។ កំណត់ហេតុការសម្រេចចិត្តផ្តល់បរិបទនៃគម្រោង ព្រមទាំងព័ត៌មានលម្អិតអំពីការអនុវត្ត និងការរចនា។ សមាជិកគម្រោងរំលឹកមើលចំណងជើងនៃ ADR នីមួយៗដើម្បីទទួលបានទិដ្ឋភាពទូទៅនៃបរិបទគម្រោង។ ពួកគេអាន ADR ដើម្បីស្វែងយល់ឱ្យស៊ីជម្រៅអំពីការអនុវត្តគម្រោង និងជម្រើសនៃការរចនា។

នៅពេលក្រុមទទួលយក ADR មួយ វាក្លាយជារឿងមិនអាចផ្លាស់ប្តូរបាន។ ប្រសិនបើការយល់ដឹងថ្មីតម្រូវឱ្យមានការសម្រេចចិត្តផ្សេង ក្រុមស្នើ ADR ថ្មីមួយ។ នៅពេលក្រុមទទួលយក ADR ថ្មីនោះ វាជំនួស ADR ពីមុន។

វិសាលភាពនៃដំណើរការ ADR

សមាជិកគម្រោងគួរបង្កើត ADR សម្រាប់រាល់ការសម្រេចចិត្តដែលមានសារៈសំខាន់ខាងស្ថាបត្យកម្មដែលប៉ះពាល់ដល់គម្រោង ឬផលិតផលកម្មវិធី រួមមានដូចតទៅ (Richards និង Ford 2020)៖

  • រចនាសម្ព័ន្ធ (ឧទាហរណ៍ គំរូដូចជា microservices)

  • តម្រូវការមិនមែនមុខងារ (សុវត្ថិភាព ភាពអាចរកបានខ្ពស់ និងការទប់ទល់នឹងកំហុស)

  • ភាពអាស្រ័យ (ការភ្ជាប់គ្នារវាងសមាសភាគ)

  • ចំណុចប្រទាក់ (API និងកិច្ចសន្យាដែលបានផ្សព្វផ្សាយ)

  • បច្ចេកទេសសាងសង់ (បណ្ណាល័យ ក្របខ័ណ្ឌ ឧបករណ៍ និងដំណើរការ)

  • តម្រូវការមុខងារ និងមិនមែនមុខងារ គឺជាធាតុបញ្ចូលដែលសាមញ្ញបំផុតនៃដំណើរការ ADR។

មាតិកា ADR

នៅពេលក្រុមកំណត់អត្តសញ្ញាណតម្រូវការ ADR សមាជិកក្រុមម្នាក់ចាប់ផ្តើមសរសេរ ADR ដោយផ្អែកលើពុម្ពសម្រាប់ទាំងគម្រោង។ (សូមមើលអង្គការ ADR នៅលើ GitHub សម្រាប់ពុម្ពគំរូ។) ពុម្ពធ្វើឱ្យការបង្កើត ADR កាន់តែងាយស្រួល និងធានាថា ADR កត់ត្រាព័ត៌មានពាក់ព័ន្ធទាំងអស់។ យ៉ាងតិច ADR នីមួយៗគួរកំណត់បរិបទនៃការសម្រេចចិត្ត ការសម្រេចចិត្តខ្លួនឯង និងផលវិបាកនៃការសម្រេចចិត្តចំពោះគម្រោង និងលទ្ធផលដែលត្រូវប្រគល់។ (សម្រាប់ឧទាហរណ៍នៃផ្នែកទាំងនេះ សូមមើលឧបសម្ព័ន្ធ។) ទិដ្ឋភាពដ៏មានអានុភាពបំផុតមួយនៃរចនាសម្ព័ន្ធ ADR គឺវាផ្តោតលើហេតុផលនៃការសម្រេចចិត្ត ជាជាងរបៀបដែលក្រុមអនុវត្តវា។ ការយល់ដឹងពីមូលហេតុដែលក្រុមធ្វើការសម្រេចចិត្តនោះ ធ្វើឱ្យសមាជិកក្រុមផ្សេងទៀតងាយទទួលយកការសម្រេចចិត្តនេះ និងការពារមិនឱ្យស្ថាបត្យករផ្សេងទៀតដែលមិនបានចូលរួមក្នុងដំណើរការសម្រេចចិត្តបដិសេធការសម្រេចចិត្តនោះនៅពេលអនាគត។

ដំណើរការទទួលយក ADR

សមាជិកក្រុមគ្រប់រូបអាចបង្កើត ADR បាន ប៉ុន្តែក្រុមគួរបង្កើតនិយមន័យនៃភាពជាម្ចាស់សម្រាប់ ADR។ អ្នកនិពន្ធនីមួយៗដែលជាម្ចាស់នៃ ADR គួរថែរក្សា និងទំនាក់ទំនងមាតិកា ADR ដោយសកម្ម។ ដើម្បីបញ្ជាក់ភាពជាម្ចាស់នេះ មគ្គុទ្ទេសក៍នេះហៅអ្នកនិពន្ធ ADR ថាជាម្ចាស់ ADR នៅក្នុងផ្នែកខាងក្រោម។ សមាជិកក្រុមផ្សេងទៀតអាចចូលរួមចំណែកក្នុង ADR បានជានិច្ច។ ប្រសិនបើមាតិកានៃ ADR ផ្លាស់ប្តូរមុនពេលក្រុមទទួលយក ADR នោះ ម្ចាស់គួរអនុម័តការផ្លាស់ប្តូរទាំងនេះ។

បន្ទាប់ពីក្រុមកំណត់អត្តសញ្ញាណការសម្រេចចិត្តខាងស្ថាបត្យកម្ម និងម្ចាស់របស់វា ម្ចាស់ ADR ផ្តល់ ADR ក្នុងស្ថានភាព បានស្នើ (Proposed) នៅដើមដំណើរការ។ ADR ក្នុងស្ថានភាពបានស្នើ គឺរួចរាល់សម្រាប់ការពិនិត្យ។

បន្ទាប់មក ម្ចាស់ ADR ចាប់ផ្តើមដំណើរការពិនិត្យសម្រាប់ ADR។ គោលដៅនៃដំណើរការពិនិត្យ ADR គឺដើម្បីសម្រេចថាតើក្រុមទទួលយក ADR កំណត់ថាវាត្រូវកែសម្រួលឡើងវិញ ឬបដិសេធ ADR។ ក្រុមគម្រោង រួមទាំងម្ចាស់ ពិនិត្យ ADR។ កិច្ចប្រជុំពិនិត្យគួរចាប់ផ្តើមដោយមានរយៈពេលផ្ទាល់សម្រាប់អាន ADR។ ជាមធ្យម ១០ ទៅ ១៥ នាទីគួរតែគ្រប់គ្រាន់។ ក្នុងអំឡុងពេលនេះ សមាជិកក្រុមម្នាក់ៗអានឯកសារ ហើយបន្ថែមមតិយោបល់ និងសំណួរដើម្បីសម្គាល់ប្រធានបទដែលមិនច្បាស់។ បន្ទាប់ពីដំណាក់កាលពិនិត្យ ម្ចាស់ ADR អានចេញសម្លេង និងពិភាក្សាមតិយោបល់នីមួយៗជាមួយក្រុម។

ប្រសិនបើក្រុមរកឃើញចំណុចសកម្មភាពដើម្បីកែលម្អ ADR នោះស្ថានភាពរបស់ ADR នៅតែជា បានស្នើ។ ម្ចាស់ ADR រៀបចំសកម្មភាព ហើយសហការជាមួយក្រុម បន្ថែមអ្នកទទួលខុសត្រូវសម្រាប់សកម្មភាពនីមួយៗ។ សមាជិកក្រុមម្នាក់ៗអាចចូលរួម និងដោះស្រាយចំណុចសកម្មភាព។ ម្ចាស់ ADR មានទំនួលខុសត្រូវក្នុងការកំណត់កាលវិភាគដំណើរការពិនិត្យឡើងវិញ។

ក្រុមក៏អាចសម្រេចបដិសេធ ADR ដែរ។ ក្នុងករណីនេះ ម្ចាស់ ADR បន្ថែមហេតុផលនៃការបដិសេធ ដើម្បីជៀសវាងការពិភាក្សាម្តងទៀតលើប្រធានបទដូចគ្នានាពេលអនាគត។ ម្ចាស់ប្តូរស្ថានភាព ADR ទៅជា បានបដិសេធ (Rejected)។

ប្រសិនបើក្រុមអនុម័ត ADR ម្ចាស់បន្ថែមត្រាពេលវេលា កំណែ និងបញ្ជីភាគីពាក់ព័ន្ធ។ បន្ទាប់មកម្ចាស់ធ្វើបច្ចុប្បន្នភាពស្ថានភាពទៅជា បានទទួលយក (Accepted)។

ADR និងកំណត់ហេតុការសម្រេចចិត្តដែលពួកវាបង្កើត តំណាងឱ្យការសម្រេចចិត្តដែលក្រុមបានធ្វើ ហើយផ្តល់ប្រវត្តិនៃការសម្រេចចិត្តទាំងអស់។ ក្រុមប្រើ ADR ជាឯកសារយោងក្នុងអំឡុងពេលពិនិត្យកូដ និងពិនិត្យស្ថាបត្យកម្មតាមដែលអាចធ្វើទៅបាន។ បន្ថែមលើការពិនិត្យកូដ កិច្ចការរចនា និងកិច្ចការអនុវត្ត សមាជិកក្រុមគួរពិគ្រោះ ADR សម្រាប់ការសម្រេចចិត្តជាយុទ្ធសាស្ត្រសម្រាប់ផលិតផល។

ជាការអនុវត្តល្អ ការផ្លាស់ប្តូរកម្មវិធីនីមួយៗគួរឆ្លងកាត់ការពិនិត្យដោយមិត្តរួមការងារ ហើយតម្រូវឱ្យមានការអនុម័តយ៉ាងតិចមួយ។ ក្នុងអំឡុងពេលពិនិត្យកូដ អ្នកពិនិត្យកូដអាចរកឃើញការផ្លាស់ប្តូរដែលរំលោភលើ ADR មួយ ឬច្រើន។ ក្នុងករណីនេះ អ្នកពិនិត្យសុំឱ្យអ្នកនិពន្ធនៃការផ្លាស់ប្តូរកូដធ្វើបច្ចុប្បន្នភាពកូដ ហើយចែករំលែកតំណភ្ជាប់ទៅ ADR។ នៅពេលអ្នកនិពន្ធធ្វើបច្ចុប្បន្នភាពកូដ វាត្រូវបានអនុម័តដោយអ្នកពិនិត្យមិត្តរួមការងារ ហើយបញ្ចូលចូលក្នុងមូលដ្ឋានកូដមេ។

ដំណើរការពិនិត្យ ADR

ក្រុមគួរចាត់ទុក ADR ជាឯកសារដែលមិនអាចផ្លាស់ប្តូរបាន បន្ទាប់ពីក្រុមទទួលយក ឬបដិសេធវា។ ការផ្លាស់ប្តូរ ADR ដែលមានស្រាប់ តម្រូវឱ្យបង្កើត ADR ថ្មី បង្កើតដំណើរការពិនិត្យសម្រាប់ ADR ថ្មី និងអនុម័ត ADR នោះ។ ប្រសិនបើក្រុមអនុម័ត ADR ថ្មី ម្ចាស់គួរប្តូរស្ថានភាពនៃ ADR ចាស់ទៅជា ត្រូវបានជំនួស (Superseded)។