Architectural Decision Records (ADRs) คืออะไร?

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 ผมมักจะโยงถึงเรื่องของการเขียนด้วยเช่นกัน ผมเขียนอธิบายไว้ในบทความด้านล่างนี้

เพราะว่าถ้าเราไม่เขียน เราไม่จารึกสิ่งนั้นไว้เป็นประวัติศาสตร์ของเรา ไม่นานเราก็จะลืม และสิ่งนั้นจะค่อย ๆ หายไปจากโลกนี้

สถาปัตยกรรมที่ดีไม่ใช่แค่โค้ดที่เขียนในวันนี้ แต่คือเหตุผลที่เรายังยืนหยัดกับมันได้ในวันข้างหน้า — และ ADR คือความทรงจำของสถาปัตยกรรมนั้น

ใครยังไม่ได้เริ่มเขียน ADR วันนี้เริ่มเลยนะ 😉

Values ของ Framework ต่าง ๆ

ผมหาคุณค่า (Values) ของผมเจอจากการสังเกตความต้องการที่มักจะมาหาผมบ่อย ๆ ทั้งตอนที่มันได้รับการตอบสนองและทำให้ผมรู้สึกดีมาก ๆ รวมถึงตอนที่มันไม่ได้รับการตอบสนองและทำให้ผมปั่นป่วนมาก ๆ พอความต้องการไหนมาเคาะประตูใจผมบ่อย ๆ ผมก็เริ่มพิจารณาว่าความต้องการนี้แหละที่เป็น Value หนึ่งสำหรั

Accepted Responsibility

ช่วงนี้ผมกำลังอ่านหนังสือ Extreme Programming Explained ของ Kent Beck แล้วก็ได้เจอหัวข้อหนึ่งที่กระทบใจ คือ principle ที่เรียกว่า Accepted Responsibility Principle คืออะไร? ในหนังสืออธิบายว่า Principle คือหลักการที่ทำให้ Values ของ XP กลายเป็น Practices ได้

The Five Ideals

จากหนังสือ The Unicorn Project ในนั้นจะมีที่ปรึกษาเก่ง ๆ คนหนึ่งชื่อ Erik เป็นเหมือนเซ็นเซหาตัวยาก เดี๋ยวก็มา เดี๋ยวก็ไป ถ้าโชคดีก็จะเจอเค้าว่าง แล้วเค้าก็จะสอนอะไรที่สำคัญ ๆ แต่ฟังดูล้ำ ๆ และลึกซึ้ง

Communication, Reliability and Modern concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ System Design โดยต่อยอดจากตัวอย่าง Gym Application เพื่อให้เห็นภาพว่า เมื่อระบบเริ่มเติบโตและถูกแยกออกเป็นหลาย Service แต่ละ Service จะสื่อสารและทำงานร่วมกันอย่างไร งานแบบไหนควรสื่อสารแบบ Synchronous งานแบบไหนควรประมวลผลแบบ Asynchronous รวมถึงอธิบาย Concept พื้นฐานต่าง ๆ ที่ควรรู้ เช่น API