Laws of Software Architecture
ทุกอย่างคือการแลกเปลี่ยน · ทำไมสำคัญกว่าอย่างไร
ใจความสำคัญ
หัวข้อที่มีชื่อว่า “ใจความสำคัญ”สถาปัตยกรรมซอฟต์แวร์เป็นสาขาที่กว้างมากจนดูเหมือนไม่มีกฎตายตัว แต่ Neal Ford และ Mark Richards ผู้เขียน Fundamentals of Software Architecture และ Software Architecture: The Hard Parts ได้กลั่นประสบการณ์การเป็นสถาปนิกมาหลายสิบปีให้เหลือกฎพื้นฐานเพียงสองข้อ ที่พวกเขาเรียกตรง ๆ ว่า “กฎ” (Laws) เพราะเชื่อว่ามันเป็นจริงแทบจะไม่มีข้อยกเว้น
กฎข้อที่หนึ่ง (First Law): ทุกอย่างในสถาปัตยกรรมซอฟต์แวร์คือการแลกเปลี่ยน (Everything in software architecture is a trade-off)
หากสถาปนิกคิดว่าค้นพบสิ่งที่ไม่ใช่การแลกเปลี่ยน แปลว่าเขายัง ไม่พบ การแลกเปลี่ยนนั้นต่างหาก มันมีอยู่เสมอ อย่างน้อยก็ในรูป opportunity cost เพราะการเลือกใช้สิ่งหนึ่งย่อมหมายถึงการเลือกไม่ใช้ทางเลือกอื่นไปโดยปริยาย
กฎข้อที่สอง (Second Law): “ทำไม” สำคัญกว่า “อย่างไร” (Why is more important than how)
มีหลายวิธีที่จะ implement สถาปัตยกรรมหนึ่ง ๆ ให้สำเร็จ และรายละเอียดการ implement ก็สำคัญไม่น้อย แต่สิ่งที่สำคัญกว่าจากมุมของสถาปนิกคือเหตุผลเบื้องหลังว่า ทำไม จึงเลือกแนวทางนั้นเหนือทางเลือกอื่น เพราะบริบท ข้อจำกัด และเป้าหมายทางธุรกิจเปลี่ยนไปตามกาลเวลา คนที่มาทีหลังต้องเข้าใจเหตุผลเดิมก่อนจะแก้ไขหรือรื้อสถาปัตยกรรมนั้น
ความหมายและนัยยะ
หัวข้อที่มีชื่อว่า “ความหมายและนัยยะ”กฎทั้งสองข้อนี้ทำงานเสริมกัน ไม่ใช่แยกจากกัน กฎข้อแรกบอกว่า “ไม่มีสถาปัตยกรรมที่ดีที่สุด” มีแต่ชุดของการแลกเปลี่ยนที่เหมาะกับบริบทหนึ่ง ๆ Richards และ Ford ใช้คำว่า least worst architecture เพื่อสื่อว่าเป้าหมายของสถาปนิกไม่ใช่การไล่หาคำตอบที่สมบูรณ์แบบ (ซึ่งไม่มีอยู่จริง) แต่คือการเลือกชุดของข้อเสียที่ยอมรับได้มากที่สุดสำหรับทีม งบประมาณ กำหนดเวลา หนี้ทางเทคนิคที่มีอยู่ และเป้าหมายทางธุรกิจของตน
ตัวอย่างคลาสสิกของการแลกเปลี่ยน เช่น การเพิ่มความปลอดภัย (เข้ารหัส ตรวจสอบสิทธิ์เพิ่มชั้น) มักแลกมาด้วยประสิทธิภาพที่ลดลง หรือการออกแบบเพื่อ scalability สูงมักเพิ่มความซับซ้อนในการปฏิบัติงาน (operational complexity) และต้นทุนที่สูงขึ้น ไม่มีทางเลือกใดที่ “ได้ทุกอย่างโดยไม่เสียอะไร” — นี่คือเหตุผลที่คำตอบยอดฮิตของคำถามด้านสถาปัตยกรรมเกือบทุกข้อคือ “it depends”
กฎข้อที่สองขยายผลจากข้อแรก เมื่อทุกการตัดสินใจคือการแลกเปลี่ยน สิ่งที่ทีมในอนาคตต้องรู้ไม่ใช่แค่ สิ่งที่ ถูกสร้างขึ้นมา แต่คือ เหตุผล ที่นำไปสู่การเลือกนั้น มิเช่นนั้นทีมจะติดอยู่ในสิ่งที่ Ford และ Richards เรียกว่า “Groundhog Day” anti-pattern คือการหยิบยกการตัดสินใจเดิมขึ้นมาถกเถียงซ้ำแล้วซ้ำเล่าเพราะไม่มีใครจำได้ (หรือไม่เคยรู้) ว่าทำไมจึงตัดสินใจอย่างนั้น เครื่องมือที่ตอบโจทย์นี้โดยตรงคือ Architecture Decision Records (ADR) ซึ่ง Michael Nygard เสนอไว้ตั้งแต่ปี 2011 — เอกสารสั้น ๆ ที่บันทึก บริบท (context), การตัดสินใจ (decision), และผลที่ตามมา (consequences) เก็บไว้ใน source control ใกล้กับ code ที่ได้รับผลกระทบ Martin Fowler อธิบายเสริมว่าคุณค่าของ ADR ไม่ได้อยู่แค่ที่การเก็บประวัติไว้ให้คนรุ่นหลังอ่าน แต่อยู่ที่ กระบวนการเขียน เองก็ช่วยบีบให้ความคิดของทีมชัดเจนขึ้น และมักเผยให้เห็นมุมมองที่ต่างกันตั้งแต่ก่อนลงมือทำ
ทั้งสองกฎยังเตือนสถาปนิกให้ระวังกับดักสองแบบ: (1) การไล่หาสถาปัตยกรรมในอุดมคติที่ไม่มีข้อเสีย ซึ่งนำไปสู่ analysis paralysis และ (2) การใช้ pattern หรือ tool หนึ่งกับทุกปัญหาโดยไม่ทบทวนบริบท ซึ่งคือ Golden Hammer anti-pattern
ตัวอย่างในโลกจริง
หัวข้อที่มีชื่อว่า “ตัวอย่างในโลกจริง”- Microservices เทียบกับ Monolith — microservices ให้ decoupling และ scalability ระดับบริการสูง แต่แลกมาด้วยความซับซ้อนของระบบกระจาย (network latency, distributed transaction, observability ที่ต้องลงทุนเพิ่ม) ส่วน monolith ให้ความเรียบง่ายในการ deploy และ debug แต่แลกมาด้วยข้อจำกัดเรื่อง scaling แยกส่วนและ blast radius ที่กว้างกว่าเมื่อเกิด bug
- Event-driven architecture — ให้ความสามารถ scale และ decouple ระหว่างบริการได้ดีเยี่ยม แต่แลกมาด้วยความยากในการ debug workflow แบบ end-to-end และการจัดการ error handling / eventual consistency
- CQRS (ดู CQRS) คือตัวอย่างรูปธรรมของกฎข้อแรก: การแยก model สำหรับอ่านและเขียนแลกความเรียบง่ายของ CRUD model เดียวไปกับความสามารถในการ optimize การอ่านและเขียนแยกกัน ทีมต้องรู้ ทำไม จึงยอมรับความซับซ้อนนี้ ไม่ใช่แค่รู้ วิธี implement
- Conway’s Law ในทางปฏิบัติ (ดู Conway’s Law) — เวลาสถาปนิกเลือกว่าจะแบ่งระบบเป็นกี่บริการ ก็มักถูกจำกัดโดยโครงสร้างทีมที่มีอยู่จริง การฝืนเลือก “สถาปัตยกรรมที่ดีที่สุดในทางทฤษฎี” โดยไม่คำนึงถึงทีมที่ต้องดูแลมันในระยะยาว มักเป็นการแลกเปลี่ยนที่ไม่คุ้ม
- ทีมที่นำ ADR มาใช้จริงในองค์กร (เช่นแนวทางที่ ThoughtWorks และทีมวิศวกรรมจำนวนมากใช้) รายงานว่าการถกเถียงซ้ำเรื่องเดิม (“ทำไมเราไม่ใช้ X แทน”) ลดลงอย่างชัดเจน เพราะมีเอกสารอ้างอิงบริบทและเหตุผล ณ เวลาที่ตัดสินใจ
flowchart LR Drivers[Business Drivers] --> Options[Candidate Options] Options --> Tradeoff[Tradeoff Analysis] Tradeoff --> Choice[Least Worst Option] Choice --> ADR[Document Why in ADR]
บทเรียนที่นำไปใช้
หัวข้อที่มีชื่อว่า “บทเรียนที่นำไปใช้”- เมื่อถูกถามว่า “สถาปัตยกรรมไหนดีที่สุด” ให้ตอบกลับด้วยคำถามว่า “ดีที่สุดสำหรับ quality attribute ไหน ในบริบทไหน” แล้วชี้ให้เห็นการแลกเปลี่ยนที่ต้องเลือก
- ทุกครั้งที่เลือกสถาปัตยกรรมหรือ pattern ให้ถามตัวเองว่า “เรากำลังแลกอะไรกับอะไร” หากตอบไม่ได้ แปลว่ายังวิเคราะห์ไม่ลึกพอ ไม่ใช่ว่าไม่มีการแลกเปลี่ยน
- เขียน ADR สั้น ๆ ทุกครั้งที่มีการตัดสินใจสำคัญ โดยเน้นที่ context และ why ให้ชัดกว่าฝั่ง how เก็บไว้ใน repository ใกล้ code ที่เกี่ยวข้อง เพื่อป้องกัน Groundhog Day anti-pattern
- อย่าไล่ตาม “สถาปัตยกรรมที่สมบูรณ์แบบ” เป้าหมายที่เป็นจริงคือ least worst architecture ที่เหมาะกับทีม งบ เวลา และหนี้ทางเทคนิคที่มีอยู่จริง
- ทบทวน ADR เก่าเป็นระยะ บริบททางธุรกิจเปลี่ยน การแลกเปลี่ยนที่เคยคุ้มค่าอาจไม่คุ้มค่าอีกต่อไป — แต่การ supersede ควรมีเอกสารใหม่อ้างอิงของเก่า ไม่ใช่แก้ทับของเดิม
ที่เกี่ยวข้อง
หัวข้อที่มีชื่อว่า “ที่เกี่ยวข้อง”- Tolerance for Imperfection
- Architectural Agility
- Common Architectural Vision
- Conway’s Law
- CQRS
- Golden Hammer
แหล่งอ้างอิง
หัวข้อที่มีชื่อว่า “แหล่งอ้างอิง”- ที่มา · deviq.com/laws/laws-software-architecture
- Fundamentals of Software Architecture — Neal Ford, Mark Richards (O’Reilly, 2020)
- Fundamentals of Software Architecture — Summary & Notes — Christian B. B. Houmann
- Book notes: Fundamentals of Software Architecture — Dan Lebrero
- bliki: Architecture Decision Record — Martin Fowler