What is Software Architecture?
โดยปกติผมมักจะเริ่มเนื้อหาด้วยการอธิบายความหมายของหัวข้อที่ต้องการจะเขียน เช่น Software Architecture คืออะไร แต่สำหรับครั้งนี้ ผมขอสารภาพเลยว่าผมก็เองก็ยังไม่สามารถเขียนหรืออธิบายความหมายของคำคำนี้ให้สั้นและกระชับได้
การเปรียบเปรยที่นิยมใช้เมื่อเราพูดถึงเรื่อง Software Architecture คือ Building plan หรือ แบบแปลนอาคาร ถ้าใครเคยเห็นแบบแปลนของอาคารจะมีเส้นและช่องสี่เหลี่ยมทั้งหมดที่จำเป็นสำหรับการสร้างอาคาร เพื่ออธิบายถึงรูปทรง จำนวนห้อง ชั้น ขนาด ผนัง บันไดและอื่นๆ เช่นเดียวกับที่ Software Architecture ที่ระบุโครงสร้างต่าง ๆ เช่น User Interfaces, Services, Databases และ Communication Protocols
ในบทความนี้เราจะมาทำความรู้จักคำว่า Software Architecture ให้มากขึ้น โดยผ่านมุมมอง Building plan กันครับ แต่ก่อนที่ก้าวเข้าสู่ดินแดนของความมึนงงและสับสนไปมากกว่านี้ ตอนนี้ที่เรายังเหลือพลังในการโฟกัส ผมอยากแนะนำเรารู้จัก “กฎ” สำคัญ 3 ข้อของโลก Software Architecture กันก่อน
“กฎ” (Laws) ของ Software Architecture
⚖️ Law #1: Everything in Software Architecture Is a Trade-Off ทุกการตัดสินใจในด้านสถาปัตยกรรมล้วนมี “Trade-Off” การเลือกแนวทางหนึ่ง ย่อมหมายถึงการสละข้อดีของอีกแนวทางหนึ่ง
🧭 Law #2: Why Is More Important Than How สิ่งสำคัญในการออกแบบซอฟต์แวร์คือ Why สำคัญมากกว่า How ควรรู้ว่า “ทำไมเราถึงตัดสินใจแบบนี้” เพราะอะไร มีเงื่อนไขอะไร ข้อจำกัดอะไร หรือเหตุผลอะไรที่อยู่เบื้องหลังการตัดสินใจนี้
🌈 Law #3: Most Architecture Decisions Aren’t Binary But Rather Exist on a Spectrum Between Extremes การตัดสินใจใน Software Architecture ไม่ใช่คำตอบแบบไอ้แดงหรือไอ้เขียว ขาวกับดำแต่คือการเลือกจุดที่เหมาะสมของบริบท ณ ช่วงเวลานั้น โดยมองภาพรวมของธุรกิจ ทีมและข้อจำกัดต่าง ๆ
The Dimensions of Software Architecture
ถ้าคุณเคยเห็นคลิป Tiktok หรือ Reels ที่เกี่ยวกับ Renovate บ้านหรือห้องภายในบ้าน สิ่งแรกที่ในคลิปมักจะพูดถึงคือขนาดของพื้นที่ เช่น วันนี้เราจะพามาดูตัวอย่างการ Renovate ห้องนอน ขนาดกว้าง 4 เมตร ยาว 5 เมตร และมีเพดานสูง 2.5 เมตร …
การอธิบายขนาดของห้องให้ครบถ้วน ต้องระบุมิติทั้ง 3 มิติ คือ ความสูง ความยาว และความกว้างและนี่คือหนึ่งในเหตุผลว่าทำไมการ “นิยาม” ความหมายของ Software Architecture จึงเป็นเรื่องท้าทาย เพราะเราไม่สามารถอธิบายหรือหาความหมายให้ผ่านมุมมองเพียงมิติเดียวได้
Mark Richards กูรูด้านนี้ (คนนี้เขียนหนังสือ Software Architecture Fundamentals) ตัวเค้าเองอธิบายว่า Software Architecture ประกอบด้วย 4 มิติ หลักๆ คือ Architectural Characteristics, Architectural Decisions , Logical Components และ Architectural Style
เดี๋ยวผมจะพาคุณเปิดประตูบ้าน ถอดรองเท้า เก็บกระเป๋า นั่งแอ่นหลังโซฟา แล้วค่อยๆ ทำความรู้จักไปทีละมิติกัน
Architecture Characteristics
ย้อนกลับไปช่วงมหาลัย ถ้าใครเรียนสาย Software คงจะเคยได้ยินว่า เราสามารถแยก Requirement ออกเป็น 2 ประเภท คือ Functional Requirements และ Non-Functional Requirements Architecture Characteristics หรือที่เรียกว่า -ilities ก็คือ Non-Functional มิตินี้อธิบายถึงคุณสมบัติอื่นๆ ที่เราอยากได้จากระบบ นอกเหนือจากใน Requirements ตัวอย่างเช่น “ระบบต้องทำงานได้ 24/7 ไม่ล่ม” , “ต้องรองรับปริมาณการใช้งานได้ 1 ล้าน user ต่อวัน” ความต้องการเหล่านี้ไม่ได้มาจากความต้องการของผู้ใช้โดยตรง ไม่ถูกเขียนไว้ใน User Story หรือ Requirement Document มักจะมาในรูปแบบของคำพูด เราในฐานะคนที่มีสกิลการพัฒนา Software มีหน้าที่ในการ “แปล” คำพูดเหล่านี้ให้สามารถจับต้องได้
Non-Functional นั่นมีเยอะมาก ๆ จนมีคำพูดตลกร้ายที่บอกว่า บางครั้งเราสามารถเพิ่ม “-ility” ต่อท้ายคำอะไรก็ได้เพื่อนิยาม Non-Functiona ที่เราต้องการ ในรูปด้านบนเป็นเพียงส่วนหนึ่งเรามักเจอบ่อย ๆ มาลองจำลองสถานการณ์ที่แปลจากคำว่า พูด เป็น Non-Functional
- “ต้องประมวลผลเร็ว รองรับลูกค้าได้หลักล้านคน” → หมายถึง ต้องให้ความสำคัญกับ Performance ยังต้องพิจารณา Scalability (ขยายระบบเมื่อมีข้อมูลมากขึ้น), Reliability (ระบบต้องไม่ล่ม), และ Availability (ต้องเข้าถึงระบบได้ตลอด)
- “ต้องลด time-to-market ให้เร็วขึ้น” → หมายถึง ไม่ใช่แค่เขียนโค้ดเร็ว แต่ต้องมี Agility, Testability (ทดสอบได้ง่ายและเร็ว), Deployability (ปล่อยระบบได้เร็วและเสถียร)
- “เวลาน้อย งบน้อย” → คำว่า Feasibility สำคัญที่สุดในกรณีนี้ เพราะไม่ว่าระบบจะดีแค่ไหน ถ้าไม่สามารถทำได้ในเวลาหรือทรัพยากรที่มี ก็ไม่มีประโยชน์ สิ่งนี้คือ Feasibility
ในโลกแห่งความจริงผมเข้าใจนะ มันไม่ได้ตรงไปตรงมาขนาดนั่น แต่อย่างน้อยถ้าเรารู้จัก Non-Functional ติดตัวไว้สัก 10–12 แบบ เอาไว้ใช้ในเวลาที่ต้องโชว์ไก่ก็เป็นเรื่องสนุกไปอีกแบบ นอกจากรูปด้านบนในหนังสือยังมี Architecture Characteristics Worksheet ถ้าใครสนใจลองหาอ่านเพิ่มเติมได้ครับ
Architecture Decisions
ย้อนกลับไปแบบแปลนของบ้านก่อนหน้านี้ บ้านหลังนี้จะสร้างชั้นเดียวหรือสองชั้น หลังคาควรเป็นแบบเรียบหรือทรงจั่ว สร้างบ้านสไตล์แรนช์ขนาดใหญ่ที่กว้างขวาง การตัดสินใจเหล่านี้มีผลกับสถาปัตยกรรมของบ้าน
Architecture Decisions คือมิติที่อธิบายถึง การตัดสินใจเรื่องต่าง ๆ ที่มีผลกระทบระยะยาวต่อระบบ อธิบายถึงข้อจำกัดที่เจอ ณ ช่วงเวลานั้น ผลกระทบที่ตามมาหลังจากการตัดใจ เป็นแนวทางสำหรับใช้ในการวางแผน และเป็นเครื่องมือไว้ช่วย Track การตัดสินใจต่างๆ ทำให้เข้าใจภาพรวม เรื่องราวว่าทำไมถึงเลือกตัดสินใจในสถานการณ์นั้นๆ
ตัวอย่างเช่น เราตกลงกันว่าจะให้เฉพาะ Data Access Service เท่านั้นที่สามารถเข้าถึง Database ได้ เพื่อให้สามารถควบคุมข้อมูล ลด Coupling ระหว่าง UI กับ Database โดยตรง แยกความรับผิดชอบอย่างชัดเจน (Separation of Concerns) ควบคุมการเข้าถึงข้อมูลได้อย่างเป็นระบบ แต่ Trade-offs คือเพิ่มความซับซ้อนของระบบ ต้องจัดการ Layer เพิ่มขึ้น เช่น Data Access API, DTO, Mapper ฯลฯ
ยิ่งระบบมีขนาดใหญ่และซับซ้อนมากเท่าไหร่ ก็จะมีเอกสารกระจัดกระจายตามมามากเท่านั้น แต่ละเอกสารมักจะมีรูปแบบการเขียนที่แตกต่างกันขึ้นอยู่กับความสร้างสรรค์ของแต่ละคน หนึ่งในแนวทางที่ได้รับความนิยม เพื่อเรามีรูปแบบที่เป็นมาตรฐานเดียว คือ Architecture Decision Record (ADR) ถ้าใครสนใจสามารถลองหาอ่านเพิ่มได้เติมได้ครับ
Logical Components
แบบแปลนของบ้านจะประกอบด้วยห้องต่างๆ เช่น ห้องครัว ห้องนอน ห้องน้ำ ห้องนั่งเล่น ห้องทำงาน และอื่นๆ แต่ละห้องมีวัตถุประสงค์การใช้งานที่แตกต่างกัน ห้องเหล่านี้เป็นตัวแทนของ Components ต่าง ๆ ภายในบ้าน
สมมุติว่าบริษัทของคุณกำลังจะเริ่ม Product ใหม่ PO เดินมาบอกว่าอยากได้ระบบซื้อขายสินค้าออนไลน์ ง่าย ๆ คล้าย Shopee app โดยมี Feature ที่อยากสำหรับ Release แรกมาให้แล้ว
แนวคิดของ Logical Components อธิบายมิติของ Components ต่างๆ ภายในระบบ จาก Feature ที่ PO อยากได้ จะต้องประกอบไปด้วย Components อะไรบ้างแบ่งหน้าที่กันรับผิดชอบอย่างไร ตัวอย่างเช่น การจะทำ Shopee app ง่าย ๆ แบบที่ PO อยากได้เนี่ย ต้องประกอบด้วย 5 Components คือ Order Tracking, Order Shipping , Processing Payments, Inventory Management และ Order Placement
สำหรับใครที่สนใจเรื่อง Logical component สามารถดูคลิป Identifying Components: The Workflow Approach เพิ่มเติมได้ครับ
Software Architecture Styles
ผมอยากให้คุณลองหลับตาแล้วนึกย้อนกลับไปถึงเมื่อวานช่วงเช้าระหว่างออกเดินทางจากที่พักไปที่ทำงาน ไม่ว่าจะขับรถหรืออยู่บนรถสาธารณะ คุณคงจะเห็น Architecture Style ของอาคาร บ้านเรือนต่าง ๆ หลาย 10 แบบแต่ละแบบที่แตกต่างกัน แต่ละแบบได้รับอิทธิพลจากสถานที่ ทิศทางฮวงจุ้ย และความชอบส่วนตัวของเจ้าของบ้าน
ในโลกของ Software มี Architecture Styles เช่นกัน มิตินี้เอาไว้เพื่อเป็น Guidelines ในการ Development ช่วยให้สื่อสารภาพใหญ่ของระบบ และเอาไว้อ้างอิงเวลาออกแบบและ Styles ยังเป็นตัวกำหนด Structure กับ Behavior ของระบบ ทำให้เราเห็นส่วนประกอบต่างๆ การไหลของข้อมูล และวิธีการทำงานของส่วนต่างๆ ของระบบ
สิ่งที่แตกต่างจาก Home Styles คือ Software Architecture Styles ยังไม่สามารถ Naming หรือตั้งชื่อเรียกให้ชัดเจนได้ ตัวอย่างเช่น ถ้าเราพูดถึง Ranch Homes จะหมายถึงบ้านที่มีเพียงชั้นเดียว หรือ Tudor Homes มักจะนึกบ้านที่มีปล่องไฟ
แต่ Software Architectural Styles คือการนำส่วนประกอบหลาย ๆ ส่วนมารวมกันเพื่อสร้าง Styles ให้กับระบบของเรา ดังนั้น Combination สามารถแบ่งได้หลากหลายหมวดหมู่มาก ๆ โดยด้านล่างนี้เป็นเพียงหมวดหมู่หลักและรูปแบบที่สามารถนำไปใช้ได้
- Domain: มุมมองของการออกแบบระบบ เราอยากให้ออกแบบโดยใช้ Principles อะไร เช่น Domain Driven Design, Monolithic หรือ Microservices เนื่องแนวคิดของแต่ละมุมมองไม่เหมือนกัน เราควรพิจารณาสิ่งนี้ตั้งแต่ Day One
- Communication: วิธีที่ระบบของเราใช้ในการสื่อสารกัน เช่น เราเลือก DDD ระหว่าง Bounded Context จะให้ Up Stream ข้อมูล ไปที่ Down Stream อย่างไร ใช้ SOA, Message Bus หรือ Event-Driven
- Deployment: เราจะ Deploy ระบบอย่างไร เช่น ถ้าเลือก Monolithic จะ Deploy ทั้ง Client/Server เป็น Binary ก้อนเดียวกันไหม หรือแยก Deploy หลาย ๆ ก้อน
- Structure: จะใช้ Structure แบบไหนเป็น Component-Based, Pipes and Filters, Layered
- Data-centric: Kappa Architecture หรือ Lambda Architecture
การกำหนด Styles ให้กับระบบเราคือการเลือกจาก 5 ข้อนี้ มาผสมกัน ตัวอย่างจากหนังสือของ Mark Richards เค้าได้แบ่ง Styles ออกเป็น 2 มุมมอง
มุมมองที่ 1: Deployment Model คือการพิจารณาว่าระบบถูก Deploy อย่างไร
- Monolithic — ทุกอย่างถูกรวมไว้เป็น Binary หรือ Deployment Unit เดียว
- Distributed — แต่ละ Service เป็น Deploy แยกกัน ที่เราคุ้นกัน Microservice, EDA
มุมมองที่ 2: Partitioning คือการพิจารณาว่าเราจัด Code Structure อย่างไร
- แบ่งตาม Technical Concerns — เช่น การแยก Layered Architecture ที่เราคุ้นเคยกันก็จะเป็น Presentation Layer, Business Logic Layer, Data Access Layer
- แบ่งตาม Domain (business) Concerns — เช่น Domain-Driven Design
Conclusion
แม้คำว่า Software Architecture จะถูกใช้กันอย่างแพร่หลาย แต่การนิยามให้กระชับและครอบคลุมกลับไม่ใช่เรื่องง่าย เพราะมันไม่ใช่แค่โครงสร้างของระบบหรือแผนผังไดอะแกรมสวย ๆ แต่คือการมองระบบทั้งระบบผ่านมุมมองหลายมิติ เหมือนกับการออกแบบบ้านที่ไม่ได้ดูแค่กว้างยาวสูง แต่ต้องเข้าใจทั้งการใช้งาน ข้อจำกัด และสภาพแวดล้อม
ผมมองว่า Software Architecture คือการตัดสินใจที่มีผลระยะยาวกับระบบ และที่สำคัญกว่าคือการเข้าใจ “Why” ว่าทำไมเราจึงเลือกทางนั้น มากกว่าจะสนใจแค่ว่าเราทำ “How” และความท้าทายคือการหาจุดสมดุลที่เหมาะสมที่สุดในบริบท ณ ช่วงเวลานั่น ๆ
Refs:
[Head First Software Architecture: A Learner’s Guide to Architectural Thinking
Head First Software Architecture: A Learner’s Guide to Architectural Thinking [Gandhi, Raju, Richards, Mark, Ford…
www.amazon.com](https://www.amazon.com/Head-First-Software-Architecture-Architectural/dp/1098134354?source=post_page-----ced80e306335---------------------------------------)
[Fundamentals of Software Architecture: A Modern Engineering Approach
Fundamentals of Software Architecture: A Modern Engineering Approach [Richards, Mark, Ford, Neal] on Amazon.com. FREE…
www.amazon.com](https://www.amazon.com/Fundamentals-Software-Architecture-Engineering-Approach/dp/1098175514/ref=sr_1_1?crid=2RFSDZIE2C1ZM&dib=eyJ2IjoiMSJ9.AjjJ724ro-V2bGONJSPbhjPvsv71U5fl7r5t9W2BJkpe3pMr5B1lRIQbQQnfxyaUqhILC-c5bwyD5Qbf7xj7vCBDmSxdeaK9FTKLGSF9GTK69XRSrpf0ZCl1OYVcKc6YW7ah54MNO378l0buAaa-P6dDC3SRuC3ICeFPquKt01iGDOw5rwxAkvMj5G-fPQsr1O4ff2-aQf6Knvww9lPvTfCZI7VXHts3Z5oF294Wa2c.w9jz4LKjrd5Qsl4t1qerk8-fRKu1vpa2VipAJhqDGNU&dib_tag=se&keywords=Software+Architecture%3A&qid=1753194723&s=books&sprefix=%2Cstripbooks-intl-ship%2C321&sr=1-1&source=post_page-----ced80e306335---------------------------------------)