Fundamental of Software Architecture: Architecture คือศิลปะของการตัดสินใจที่ทำให้ระบบอยู่ต่อได้

ขอจดโน๊ตที่ไปเรียนวิชา Fundamental of Software Architecture กับพี่รูฟมาค่ะ นี่แค่ day1 555555+

คำว่า Architecture ไม่ได้เริ่มต้นจากโลกของซอฟต์แวร์ แต่มีรากมาจากโลกของการก่อสร้าง เมือง อาคาร และ civil engineering มายาวนานมาก ก่อนที่เราจะเอาคำนี้มาใช้กับ software architecture ในภายหลัง

สิ่งที่น่าสนใจคือ ในโลกของ civil engineering หรือสถาปัตยกรรมจริง ๆ คำว่า “engineer” และ “architect” มีความหนักแน่นมาก เพราะมีศาสตร์ มีข้อจำกัดทางฟิสิกส์ มีคณิตศาสตร์ มีวัสดุ มีแรงกดทับ มีพื้นที่จริง และมีต้นทุนที่แก้พลาดได้ยากมาก

แต่ในโลกซอฟต์แวร์ บางครั้งเราถูกแซวว่า Software Engineer อาจยังไม่ค่อย “engineer” เท่าไร เพราะเราไม่ได้เรียนคณิตศาสตร์หรือวิศวกรรมเชิงกายภาพหนักเท่าคนในสายอื่น และในวงการซอฟต์แวร์เองก็มักมีวัฒนธรรมที่คนรุ่นก่อน bully คนรุ่นใหม่ หรือคนที่ทำมาก่อนมองว่าของที่คนก่อนหน้าทำไว้ไม่ดีพอ จนเกิด pattern เดิมซ้ำ ๆ คือ “rewrite ใหม่ทั้งหมด”

ปัญหาคือ ถ้าเราทำแบบนี้ไปเรื่อย ๆ ซอฟต์แวร์จะไม่มีวันกลายเป็น masterpiece ได้เลย เพราะยังไม่ทัน evolve ก็ถูกรื้อทิ้งก่อนเสมอ

Architect ในโลกก่อสร้างทำอะไร

ถ้าดูจากโลกของสถาปัตยกรรมจริง ๆ หน้าที่ของ architect ไม่ใช่แค่การวาดแบบอาคารให้สวย แต่คือการทำความเข้าใจว่าอาคารนั้นต้องตอบโจทย์อะไร ใครเป็น stakeholder และคุณภาพแบบไหนที่อาคารนั้นต้องมี

ตัวอย่างหนึ่งที่น่าสนใจคือ Senate House ของ University of London

London เป็นเมืองเก่าแก่ แต่ในอดีตมีเรื่องที่ทำให้ผู้บริหารเมืองรู้สึกเสียหน้าอยู่เหมือนกัน คือเด็กเก่ง ๆ จำนวนมากไม่ได้เลือกเรียนใน London แต่เลือกไปเรียนที่ Cambridge หรือ Oxford แทน เมืองเหล่านั้นไม่ได้มีแค่ชื่อเสียงด้านการศึกษา แต่มีบรรยากาศแบบ college town มีพื้นที่ที่โอบล้อมให้เด็ก ๆ ใช้ชีวิต เรียนรู้ และเติบโต เหมือนโลกใน Harry Potter ที่มหาวิทยาลัยไม่ได้เป็นแค่อาคารเรียน แต่เป็น ecosystem ของชีวิตนักศึกษา

London จึงต้องการสร้างบางสิ่งที่ประกาศตัวตนใหม่ของเมือง และ Senate House ก็ถูกสร้างขึ้นด้วยเจตนานั้น

“It should be something that could not have been built by any earlier generation.”

ประโยคนี้สะท้อนหัวใจของ architecture ได้ดีมาก เพราะอาคารนี้ไม่ได้ถูกออกแบบให้เป็นแค่ “ตึกหนึ่งหลัง” แต่ถูกออกแบบให้เป็น statement ว่า คนรุ่นนี้สามารถสร้างบางอย่างที่คนรุ่นก่อนสร้างไม่ได้

สิ่งที่ Architect ต้องตัดสินใจ

เมื่อ architect ออกแบบอาคาร สิ่งที่ต้องคิดไม่ใช่แค่ว่าอาคารมีกี่ชั้น หรือใช้วัสดุอะไร แต่ต้องเริ่มจากคำถามที่ลึกกว่านั้น เช่น

ใครคือ stakeholder ของอาคารนี้
อาคารนี้ต้องมีคุณภาพแบบไหน
เราจะออกแบบอย่างไรให้ได้คุณภาพเหล่านั้น
design language แบบไหนที่จะสื่อสาร decision เหล่านี้ออกมา
ส่วนประกอบจริง ๆ ของอาคารคืออะไร และแต่ละส่วนสัมพันธ์กันอย่างไร

ถ้า stakeholder ต้องการอาคารที่ดูหรูหรา อลังการ และเป็นสัญลักษณ์ของยุคสมัย architect ก็ต้องเลือก architecture style ที่สื่อสารสิ่งนั้นได้ ไม่ใช่เลือกวัสดุหรือรูปทรงแบบสุ่ม ๆ

เช่น ถ้าเราต้องการสร้างตึกที่ให้ความรู้สึก grand, elegant และ timeless เราอาจเลือกใช้หินแกรนิตหรือหินอ่อน ใช้ราวบันไดโลหะสีดำ ใช้ประตูสูง 2-3 เมตร ใช้พื้นสีครีมหรือวัสดุที่ให้ความรู้สึกมั่นคง สิ่งเหล่านี้ไม่ใช่ decoration แต่คือ architectural decision ที่ทำให้คนทุกทีมเข้าใจตรงกันว่า “เรากำลังสร้างอะไร”

Architecture Style และ Pattern คือภาษากลางของการออกแบบ

ถ้าเราเป็นทีมสถาปนิกที่ต้องออกแบบห้องสมุดให้มหาวิทยาลัยแห่งหนึ่ง สิ่งแรกที่ควรทำไม่ใช่การพยายาม “ฉีก” หรือโชว์ความสร้างสรรค์ทันที แต่ควรเริ่มจากการเข้าใจ style และ pattern ก่อน

ถ้าเราเลือก style เช่น Art Deco, Modernist, Brutalist หรือ Gothic ทุกคนในทีมจะเริ่มมีภาษากลางในการตัดสินใจทันที

เมื่อมีคนถามว่า บันไดควรเป็นแบบไหน ประตูควรสูงแค่ไหน สีควรเป็นโทนไหน วัสดุควรเป็นอะไร ทีมไม่จำเป็นต้องเริ่มถกกันใหม่ทุกครั้ง เพราะ style และ pattern ช่วยบอกขอบเขตของ decision ไว้แล้ว

นี่คือหน้าที่สำคัญของ architecture:
ทำให้คนเดินตาม decision ได้ โดยไม่ต้องเล่าทุกอย่างใหม่ซ้ำ ๆ

architecture ที่ดีจึงไม่ได้อยู่แค่ในหัวของ architect แต่ต้องสื่อสารออกมาเป็น guideline, pattern, principle และ decision ที่ทีมอื่นสามารถ follow ต่อได้

ปัญหาของโลกซอฟต์แวร์: เราชอบ Rewrite มากกว่า Evolve

ในโลกซอฟต์แวร์ เรามักเจอ pattern หนึ่งบ่อยมาก คือคนที่เข้ามาทีหลังมองว่าของเดิมไม่ดีพอ แล้วเลือก rewrite ใหม่ทั้งหมด

เหตุผลอาจฟังดูสมเหตุสมผล เช่น code เก่ายุ่ง, architecture เก่าไม่ดี, technology เก่าเกินไป, scale ไม่ได้, maintain ยาก หรือไม่มีใครเข้าใจแล้ว

แต่ถ้าเราทำแบบนี้ซ้ำไปเรื่อย ๆ เราจะไม่มีวันได้ระบบที่ mature จริง ๆ เพราะระบบไม่เคยมีเวลามากพอที่จะ evolve ทุกครั้งที่เริ่มเข้าใจปัญหา เราก็ล้มกระดานแล้วเริ่มใหม่

คำถามที่ architect ต้องตอบจึงไม่ใช่แค่ “จะออกแบบระบบใหม่อย่างไร”

แต่คือ

จะทำอย่างไรให้ระบบ evolve ต่อได้ โดยไม่ต้อง rewrite ใหม่ทั้งระบบ

นี่คือความแตกต่างระหว่างการคิดแบบ developer กับการคิดแบบ architect

developer อาจสนใจว่า feature นี้จะทำอย่างไรให้เสร็จ
แต่ architect ต้องสนใจว่า decision วันนี้จะทำให้ระบบอยู่ต่อได้อีกกี่ปี และจะเปิดทางหรือปิดทางให้ทีมในอนาคตอย่างไร

Software Architecture คือ Set of Decisions

สุดท้ายแล้ว software architecture ไม่ใช่ diagram ไม่ใช่ tech stack และไม่ใช่ชื่อ pattern เท่ ๆ อย่าง microservices, event-driven หรือ clean architecture

Software architecture คือ

ชุดของการตัดสินใจที่อธิบาย structure, boundaries, communication และ quality attributes ของระบบ

Structure คือระบบประกอบด้วยส่วนอะไรบ้าง
Boundaries คือขอบเขตของแต่ละส่วนอยู่ตรงไหน
Communication คือแต่ละส่วนคุยกันอย่างไร
Quality attributes คือระบบต้องมีคุณภาพอะไร เช่น scalability, reliability, security, maintainability, performance หรือ evolvability

สิ่งสำคัญคือ decision เหล่านี้มักเป็นสิ่งที่ “เลือกแล้วเปลี่ยนยาก” ไม่ใช่เปลี่ยนไม่ได้ แต่มี cost สูงในการเปลี่ยน

เช่น ถ้าเราเลือกให้ระบบเป็น monolith ก็จะมีข้อดีข้อเสียแบบหนึ่ง
ถ้าเราเลือก microservices ก็จะมีข้อดีข้อเสียอีกแบบหนึ่ง
ถ้าเราเลือก database shared กันทั้งองค์กร ก็จะมีผลระยะยาวแบบหนึ่ง
ถ้าเราเลือกแยก bounded context ก็จะมีผลอีกแบบหนึ่ง

ดังนั้น architect ไม่ใช่คนที่เลือกของที่ดูทันสมัยที่สุด แต่คือคนที่เข้าใจว่า decision ใดเป็น decision สำคัญ decision ใดเปลี่ยนยาก และ decision ใดควรปล่อยให้ทีมเลือกเองได้

ไม่มี Software Architecture ไหนที่แบ่งให้เล็กลงไม่ได้

อีกประเด็นที่สำคัญคือ ไม่มี software architecture ไหนที่เล็กจนแบ่งต่อไม่ได้

ระบบขนาดใหญ่สามารถแตกออกเป็น logical component ได้เสมอ คำถามคือเราจะแบ่งอย่างไร แบ่งตาม business capability หรือแบ่งตาม technical layer แบ่งตาม team ownership หรือแบ่งตาม data boundary

หน้าที่ของ architect คือการ “จิ้มให้ได้” ว่าจุดไหนคือ architectural core จุดไหนคือ hidden foundation และจุดไหนคือส่วนที่ทีมสามารถตัดสินใจเองได้

เพราะในระบบจริง ทุกอย่างไม่ได้สำคัญเท่ากันหมด

บางจุดคือฐานราก ถ้าพลาดแล้วทั้งระบบจะสั่น
บางจุดคือรายละเอียด implementation ที่เปลี่ยนได้
บางจุดคือ decision เชิง strategic
บางจุดคือ decision เชิง tactical

architect ที่ดีต้องแยกสิ่งเหล่านี้ให้ออก

Strategy คือ Hidden Foundation

งานของ architect จึงไม่ใช่การลงไปตัดสินใจทุกบรรทัดของ code แต่คือการดูแล strategic decision ที่เป็น hidden foundation ของระบบ

hidden foundation คือสิ่งที่ผู้ใช้อาจมองไม่เห็น แต่มีผลต่ออนาคตของระบบอย่างมาก เช่น

ระบบแบ่ง domain อย่างไร
ข้อมูลสำคัญอยู่ตรงไหน
บริการไหนเป็น source of truth
ทีมไหน own component ไหน
integration ระหว่างระบบใช้ principle อะไร
quality attributes ใดสำคัญที่สุด
ส่วนใดต้อง stable และส่วนใดควร flexible

สิ่งเหล่านี้คือ architectural core ที่ architect ควรเข้าใจและควรเป็นคนช่วยวางทิศทาง

ส่วนงานที่เหลือ ไม่จำเป็นต้องให้ architect ทำทั้งหมด แต่ architect ต้องสร้างทีมให้เก่งพอที่จะทำต่อได้

นี่เป็นอีกบทบาทสำคัญของ architect:
ไม่ใช่แค่สร้าง architecture แต่ต้องสร้างคนที่สามารถเดินตาม architecture นั้นได้

Architect ไม่ได้ออกแบบแค่ระบบ แต่สร้างภาษากลางให้ทีม

ถ้า architecture style ในงานก่อสร้างช่วยให้ทีมรู้ว่าควรเลือกวัสดุ สี รูปทรง และองค์ประกอบแบบไหน software architecture ก็ทำหน้าที่คล้ายกัน

มันช่วยให้ทีมรู้ว่าเวลาจะสร้าง feature ใหม่ควรวางไว้ตรงไหน
ข้อมูลควรไหลผ่าน boundary ไหน
service นี้ควรคุยกับ service นั้นโดยตรงหรือผ่าน event
logic นี้ควรอยู่ใน frontend, backend หรือ domain layer
ถ้าต้อง scale ควร scale ส่วนไหน
ถ้าต้องแก้ technical debt ควรแก้ที่จุดใดก่อน

architecture ที่ดีจึงลดแรงเสียดทานในการตัดสินใจ

ไม่ใช่เพราะทุกคนถูกบังคับให้คิดเหมือนกัน แต่เพราะทุกคนมีกรอบในการคิดร่วมกัน

บทเรียนสำคัญจาก Fundamental of Software Architecture

สิ่งที่ได้จากคลาสนี้คือ Software Architecture ไม่ใช่เรื่องของความเท่ห์ทางเทคโนโลยี แต่เป็นเรื่องของ decision ที่ทำให้ระบบมีทิศทาง

architect ต้องเข้าใจ stakeholder ต้องรู้ว่าระบบต้องมี quality attributes อะไร ต้องเลือก style และ pattern ที่ช่วยให้ทีม align กันได้ และต้องแยกให้ออกว่าอะไรคือ strategic decision ที่ควรดูแลเอง อะไรคือ tactical decision ที่ทีมสามารถตัดสินใจได้

ที่สำคัญที่สุด architect ต้องตอบคำถามให้ได้ว่า

เราจะทำอย่างไรให้ระบบนี้ evolve ต่อได้ โดยไม่ต้อง rewrite ใหม่ทุกครั้งที่คนรุ่นถัดไปเข้ามา

เพราะ masterpiece ไม่ได้เกิดจากการเริ่มใหม่ตลอดเวลา
แต่มันเกิดจากการมี foundation ที่ดีพอให้คนรุ่นต่อไปสร้างต่อได้

ใครสนใจลงเรียนคลาสนี้ ติดต่อมาได้เลยนะคะ :D