Architectural Decision Records (ADRs) คืออะไร?
Architectural Decision Records หรือ ADRs คือเอกสารสั้น ๆ ที่ใช้บันทึกการตัดสินใจด้านสถาปัตยกรรมของระบบ (Software Architecture) พร้อมเหตุผลและบริบทของการตัดสินใจนั้น เพื่อให้ทีมสามารถเข้าใจว่า
ทำไมเราถึงตัดสินใจเลือกทำระบบมาแบบนี้
และเพื่อให้ข้อแลกเปลี่ยน (trade-offs) ของการตัดสินใจเหล่านั้นสามารถเข้าถึงและเข้าใจได้ง่าย
การตัดสินใจเหล่านั้นผลกระทบโดยตรงต่อการพัฒนา การดูแลรักษา และความสามารถในการขยายระบบในหลาย ๆ กรณี เหตุผลเบื้องหลังการตัดสินใจเหล่านี้มักสูญหายไปตามกาลเวลา ทำให้เกิดความยากลำบากในการทำความเข้าใจ การปรับแก้ไข และการต่อยอดระบบในอนาคต
โครงสร้าง ADR แบบพื้นฐาน
ADR หนึ่งฉบับมักมีโครงสร้างประมาณนี้:
- Title – ชื่อการตัดสินใจ
- Status – สถานะ (Proposed / Accepted / Deprecated ฯลฯ)
- Context – ปัญหาหรือสถานการณ์ที่ทำให้ต้องตัดสินใจ
- Decision – สิ่งที่ตัดสินใจเลือก
- Consequences – ผลกระทบ ข้อดี ข้อเสีย
เมื่อไหร่ถึงเขียน ADR?
ควรเขียน ADR เมื่อการตัดสินใจนั้นเป็นการตัดสินใจที่ แก้ไขได้ยากในภายหลัง เพราะทุกการเลือกมี trade-off และเมื่อตัดสินใจแล้วต้องเดินหน้าต่อ ไม่สามารถเปลี่ยนไปมาได้ง่าย ตัวอย่างเช่น การเลือกภาษาโปรแกรม หรือการเปลี่ยนชนิดของฐานข้อมูล ซึ่งเป็นการตัดสินใจเชิงสถาปัตยกรรมที่ส่งผลระยะยาวต่อระบบ
ADR มีประโยชน์มากต่อการทำงานร่วมกับ AI
แน่นอนว่าในยุคนี้จะไม่พูดถึง AI ไม่ได้ การที่เราเขียน ADR นั้นจะช่วยให้ AI นั้นเข้าใจบริบท เหตุผล และข้อจำกัดของสถาปัตยกรรมระบบเราได้ชัดเจนขึ้น ไม่ต้องเดาเอง ทำให้คำแนะนำ การวิเคราะห์ และการช่วยตัดสินใจทางเทคนิคมีความสอดคล้องกับระบบจริงมากขึ้นอีกด้วย
จริง ๆ เวลาพูดถึง ADR ผมมักจะโยงถึงเรื่องของการเขียนด้วยเช่นกัน ผมเขียนอธิบายไว้ในบทความด้านล่างนี้
Kan Ouivirach
เพราะว่าถ้าเราไม่เขียน เราไม่จารึกสิ่งนั้นไว้เป็นประวัติศาสตร์ของเรา ไม่นานเราก็จะลืม และสิ่งนั้นจะค่อย ๆ หายไปจากโลกนี้
สถาปัตยกรรมที่ดีไม่ใช่แค่โค้ดที่เขียนในวันนี้ แต่คือเหตุผลที่เรายังยืนหยัดกับมันได้ในวันข้างหน้า — และ ADR คือความทรงจำของสถาปัตยกรรมนั้น
ใครยังไม่ได้เริ่มเขียน ADR วันนี้เริ่มเลยนะ 😉
