Laws of Software Architecture (กฎของ Software Architecture)

ตอนที่ผู้เขียนทั้งสองของเราเริ่มเขียนหนังสือฉบับพิมพ์ครั้งแรก เรามีเป้าหมายที่ทะเยอทะยาน เราหวังว่าจะค้นพบสิ่งที่ดูเหมือนจะเป็นจริงในระดับสากลเกี่ยวกับ software architecture แล้วบัญญัติมันเป็น “กฎ” (law) ของ software architecture ระหว่างที่เขียน เราคอยจับตาหาสิ่งที่พอจะบันทึกได้ เราหวังว่าจะพบสัก 10 หรือ 15 ข้อ แต่ที่น่าประหลาดใจคือ สุดท้ายเราระบุได้แค่สองกฎในฉบับพิมพ์ครั้งแรก และค้นพบเพิ่มอีกหนึ่งข้อระหว่างเขียนฉบับพิมพ์ครั้งที่สอง ตรงตามความตั้งใจเดิมของเรา กฎทั้งสามนี้ดูจะเป็นจริงในระดับสากลพอสมควร และเป็นพื้นฐานของมุมมองสำคัญหลายอย่างสำหรับ software architect ที่ทำงานจริง

เราได้เรียนรู้ First Law of Software Architecture จากการเจอมันซ้ำแล้วซ้ำเล่าโดยไม่ตั้งใจ และเราคิดว่ามันเข้าถึงแก่นของเหตุผลที่ความจริงสากลเหล่านี้ดูจะจับต้องได้ยากนัก

ทุกสิ่งใน software architecture คือ trade-off

First Law of Software Architecture

ไม่มีอะไรอยู่บน spectrum ที่สะอาดสวยงามเลย ทุกการตัดสินใจที่ software architect ทำต้องคำนึงถึงตัวแปรจำนวนมาก ที่มีค่าต่างกันไปตามสถานการณ์ Trade-off คือแก่นแท้ของการตัดสินใจด้าน software architecture

ถ้าคุณคิดว่าคุณค้นพบอะไรบางอย่างที่ ไม่ใช่ trade-off มีความเป็นไปได้สูงว่าคุณแค่ยัง ระบุ trade-off นั้นไม่เจอ…เท่านั้นเอง

Corollary 1

คุณไม่สามารถทำ trade-off analysis แค่ครั้งเดียวแล้วจบเรื่องได้

Corollary 2

ทีมงานชอบ standard และคงจะดีถ้าสถาปนิกสามารถจัด One Big Trade-off Jamboree ครั้งเดียว เพื่อตัดสินใจว่าจะใช้ architecture style ไหนเป็นค่าเริ่มต้น ส่วนต่างๆ ของ architecture ควรสื่อสารกันอย่างไร จะจัดการ shared functionality อย่างไร และการตัดสินใจอันยุ่งยากอื่นๆ อีกมากมาย แต่เราทำแบบนั้นไม่ได้ เพราะทุกสถานการณ์ต้องการให้เราประเมิน trade-off เหล่านั้นใหม่ทั้งหมด (เราเคยเห็นทีมพยายามทำแบบนี้ ตัวอย่างเช่น พยายามตั้งค่าเริ่มต้นให้ใช้แค่ choreography ใน distributed workflow เท่านั้น แต่กลับพบว่ามันได้ผลบ้างในบางครั้ง และเป็นหายนะสุดๆ ในบางครั้ง ดู “Choreography and Orchestration” สำหรับการอภิปรายของเรา)

Architecture นั้นกว้างกว่าแค่การผสมผสานขององค์ประกอบเชิงโครงสร้าง นั่นคือเหตุผลที่คำนิยามเชิงมิติของเรารวม หลักการ (principle), characteristic และอื่นๆ เข้าไว้ด้วย สิ่งนี้สะท้อนอยู่ใน Second Law of Software Architecture ของเรา

ทำไม สำคัญกว่า ทำอย่างไร

Second Law of Software Architecture

ในฐานะสถาปนิกที่มีประสบการณ์ ถ้ามีใครสักคนแสดง architecture ที่ผมไม่เคยเห็นมาก่อนให้ดู ผมสามารถเข้าใจได้ว่า มันทำงานอย่างไร แต่ผมอาจจะงงว่า ทำไม สถาปนิกหรือทีมก่อนหน้าถึงตัดสินใจแบบนั้น สถาปนิกตัดสินใจภายในบริบทที่เจาะจงมากๆ ทำให้การตัดสินใจแบบครอบคลุมกว้างๆ และเป็นสูตรสำเร็จนั้นทำได้ยาก ทำไม สถาปนิกถึงตัดสินใจแบบใดแบบหนึ่งนั้นรวมถึง trade-off ที่พวกเขาพิจารณา ซึ่งเพิ่มบริบทว่าทำไมถึงเลือกการตัดสินใจนี้ แทนที่จะเป็นอีกแบบหนึ่ง ปรากฏว่าหนึ่งในลักษณะเฉพาะของการตัดสินใจด้าน software architecture คือมันแทบไม่เคยเป็น binary เลย สิ่งนี้พาเรามาสู่ Third Law of Software Architecture

การตัดสินใจด้าน architecture ส่วนใหญ่ไม่ใช่ binary แต่อยู่บน spectrum ระหว่างสองขั้ว

Third Law of Software Architecture

ตลอดทั้งเล่ม เราจะเน้นย้ำ เหตุผล ที่สถาปนิกตัดสินใจแบบใดแบบหนึ่งพร้อมกับ trade-off เรายังเน้นเทคนิคที่ดีสำหรับการบันทึกการตัดสินใจสำคัญไว้ใน บทที่ 21

ผู้อ่านจะสังเกตเห็นกฎเหล่านี้ทำงานอยู่ตลอดทั้งเล่ม และเราแนะนำให้จำมันไว้เวลาประเมินการตัดสินใจด้าน software architecture เราจะกลับมาพูดถึงกฎเหล่านี้อีกครั้งใน บทที่ 27 พร้อมตัวอย่างเพิ่มเติม

เมื่อเรามีคำนิยามใช้งานได้ของ software architecture แล้ว มาดูตัวบทบาทนี้กันต่อเลย