See the original English version of this article here
คนไอทีส่วนใหญ่ไม่ได้ตั้งเป้าหมายที่จะเป็น Software Architect แต่มักมีเหตุการณ์ที่ทำให้ต้องเป็น Software Architect จำเป็นเมื่อ Project เล็ก ๆ กลายเป็นเรื่องยุ่งยาก บทความนี้จะแบ่ง 6 รูปแบบ Software Architecture ที่ใช้งานได้จริง ซึ่งจะช่วยให้ App ของคุณเติบโตได้โดยไม่ล้มเหลว บทความนี้ช่วยให้คุณพัฒนา App ได้อย่างชาญฉลาด กับ 6 Software Architecture Patterns ที่ Developer ทุกคนควรรู้
1. Monolithic Architecture
หากเปรียบ Software Architecture เป็นวิดีโอเกม Monolithic ถือเป็น “ชุดเริ่มต้น” ที่คุณไม่สามารถข้ามได้ ซึ่ง Monolithic Architecture เป็นวิธีที่ง่ายที่สุดและเป็นที่นิยมมากที่สุด ในการเริ่มต้นสร้าง Software โดยทุกอย่างจะรวมไว้ใน Codebase เดียว และ Deploy ร่วมกัน โดยมักจะทำงานบน Server เดียว
ดังนั้น Monolithic Architecture จะรวมเอา User Interface, ตรรกะทางธุรกิจ และการเข้าถึง Database เข้าไว้ในหน่วยเดียว ทำให้สร้างได้รวดเร็ว แก้ไขปัญหาได้ง่าย และเหมาะสำหรับ Project ขนาดเล็ก หรือ MVP (Minimum Viable Product)
เมื่อ Monolithic Architecture ทำงานได้ดี:
- Startups ในช่วงเริ่มต้น (ต้องการความเร็ว ไม่ซับซ้อน)
- เครื่องมือภายในองค์กร (มีผู้ใช้งาน ประมาณ 10 คน)
- ระบบที่ความเร็วในการ Deploy สำคัญกว่าความสามารถในการปรับขนาดได้
Monolithic Architecture อาจสร้างความเสียหายได้:
- การเพิ่มจำนวนทีมในแต่ละการอัปเดต มีความเสี่ยงที่จะทำลายส่วนที่ไม่เกี่ยวข้อง
- การปรับขนาด Service เฉพาะ คุณไม่สามารถปรับขนาด Feature เดียวได้
- การ Deploy จะกลายเป็น “ถ้าไม่ทำงาน ก็ล่มทั้งระบบ” (แบบวัดดวง)
ตัวอย่างในโลกแห่งความเป็นจริง:
Instagram เริ่มต้นจากระบบ Monolith แต่เมื่อมี User หลายล้านคนแห่เข้ามาใช้งาน Instagram จึงเริ่มแยกสิ่งต่าง ๆ ออกเป็นบริการต่าง ๆ ดังนั้นควรเริ่มต้นจากสิ่งง่าย ๆ แล้วค่อยขยายขนาดในภายหลัง
2. Layered (N-Tier) Architecture
ลองนึกภาพให้ Layered Architecture เหมือนกับลาซานญ่า ที่แต่ละชั้นจะมีหน้าที่ของตัวเอง และคุณไม่ควรผสมมันเข้าด้วยกัน เว้นแต่ว่าคุณอยากทำให้เกิดหายนะที่ร้ายแรง
Layered Architecture จะแบ่ง App ของคุณออกเป็นชั้น ๆ ในเชิงตรรกะ:
- Presentation Layer (UI, Frontend)
- Business Logic Layer (Rules, Workflows)
- Data Access Layer (Database Communication)
บางครั้งคุณอาจจะได้ยิน Layered Architecture ถูกเรียกอีกชื่อหนึ่งว่า N-Tier Architecture เมื่อแต่ละ Layer ทำงานบนเครื่อง หรือ Server ที่แตกต่างกัน
เมื่อ Layered Architecture ทำงานได้ดี:
- Web Apps แบบดั้งเดิม (ลองนึกถึง E-Commerce, Banking Portals)
- ทีมที่ต้องการขอบเขตที่ชัดเจน (“ทีมฝั่ง Frontend” เทียบกับ “Backend”)
- ระบบที่ต้องการแยกการเปลี่ยนแปลงออกจากกัน (คุณสามารถสลับ UI ได้โดยไม่ทำลาย Database)
จุดที่อาจสร้างความเสียหายได้:
- Layer มากเกินไป = การพัฒนาที่ช้าลง
- การเชื่อมโยงที่แน่นหนามากเกินไป หากคุณไม่ระมัดระวัง บริการที่เสียหายเพียงรายการเดียวอาจทำให้เกิดการล่มสลายเป็นโดมิโน่ได้
- การออกแบบที่มากเกินไป สำหรับ Apps ที่เรียบง่าย
ตัวอย่างในโลกแห่งความเป็นจริง:
Spring Boot Java Apps แบบคลาสสิกหรือ ASP.NET Projects มักจะมีการจัด Layer อย่างเป็นระเบียบ เพื่อให้การดูแลรักษาเป็นเรื่องง่าย
3. Microservices Architecture
Microservices เปรียบเสมือนการแบ่งแผนที่เกมขนาดยักษ์ของคุณ ออกเป็นด่านย่อย ๆ ซึ่งแต่ละด่านจะมีกฎเกณฑ์ ศัตรู และ Checkpoint ที่ไม่เหมือนกันในแต่ละด่าน
แทนที่จะใช้ Codebase ขนาดใหญ่เพียงอันเดียว คุณสามารถแบ่ง App ของคุณออกเป็น Service แบบอิสระ โดย Service แต่ละอย่างสามารถทำหน้าที่อย่างใดอย่างหนึ่งได้ดี (ในทางทฤษฎี) และสามารถ Deploy, Update และปรับขนาดแบบแยกกันได้
เมื่อ Microservices Architecture ทำงานได้ดี:
- ทีมงานขนาดใหญ่ทำงานในส่วนต่าง ๆ ของ App
- App ขนาดใหญ่ที่ต้องการการปรับขนาดอย่างอิสระ (เช่น การค้นหา VS การชำระเงิน)
- เมื่อคุณต้องการความยืดหยุ่นในการใช้ Tech Stacks ที่แตกต่างกัน สำหรับ Service ที่แตกต่างกัน
จุดที่อาจสร้างความเสียหายได้:
- การสื่อสารระหว่าง Service อาจกลายเป็นฝันร้ายได้
- การ Debug ระหว่าง Microservices มากกว่า 20 รายการ
- Deployment Pipelines จำเป็นต้องมีการ Deploy แบบอัตโนมัติอย่างจริงจัง แต่ถ้าทำแบบ Manual เมื่อไหร่ ระบบอาจพังทันที
ตัวอย่างในโลกแห่งความเป็นจริง:
Netflix เป็นตัวอย่างที่ดีของ Microservices ที่จัดการทุกอย่างตั้งแต่คำแนะนำเนื้อหา ไปจนถึงการเรียกเก็บเงิน แต่รู้ไหม? Netflix ใช้เวลาหลายปีกว่าจะทำได้เป็นฉบับสมบูรณ์แบบในทุกวันนี้
4. Event Driven Architecture
Event Driven Architecture เปรียบเสมือนการสร้างระบบขนาดใหญ่ที่เต็มไปด้วย “กลไกที่เรามองไม่เห็น
แทนที่จะสามารถสั่งตรง ๆ ว่า “เฮ้ ทำสิ่งนี้!” คุณแค่ตะโกนเหตุการณ์ออกไปว่า “มีการสั่งซื้อแล้ว!” แล้วใครที่ฟังก็จะตอบสนองอย่างไรก็ได้ตามที่ต้องการ
เหตุการณ์เป็นเพียงข้อเท็จจริงเล็ก ๆ: “มีบางอย่างเกิดขึ้น”
Service ต่าง ๆ จะสมัครรับฟังเหตุการณ์เหล่านั้น แล้วตัดสินใจเองว่าจะทำอะไรต่อไป ทำให้ระบบเชื่อมโยงกันอย่างหลวม ๆ และมีความยืดหยุ่นสูง
เมื่อ Event-Driven Architecture ทำงานได้ดี:
- ระบบที่ต้องการการปรับขนาดได้อย่างมาก (เช่น การชำระเงินผ่าน E-commerce และ การแจ้งเตือนแบบทันที)
- เมื่อ Service ต้องตอบสนองต่อการดำเนินการอย่างอิสระ (เช่น การเรียกเก็บเงินหลังจากซื้อการสมัครใช้งาน)
- การจัดการ Data Flows ปริมาณมาก โดยไม่ทำให้ระบบใดระบบหนึ่งติดขัด
จุดที่อาจสร้างความเสียหายได้:
- การ Debug กลายเป็นงานสืบสวน ยกตัวอย่าง “เดี๋ยวนะ… ใครเป็นคนจุดชนวนเรื่องนี้ขึ้นมาอีกครั้ง!”
- ความสอดคล้องของ Data อาจเกิดความซับซ้อนได้อย่างรวดเร็ว
- หากเหตุการณ์ต่าง ๆ ไม่ได้ถูกบันทึกไว้เป็นอย่างดี คุณอาจจะต้องใช้พลังจิต เพื่อหาคำตอบในภายหลัง
ตัวอย่างในโลกแห่งความเป็นจริง:
Amazon ใช้ Event-Driven Architecture อย่างจริงจัง เช่น การประมวลผลคำสั่งซื้อและการจัดการสินค้าคงคลัง ทุก ๆ ครั้งที่มีการสั่งซื้อ ระบบย่อยต่าง ๆ จะถูกเรียกใช้อย่างอิสระตามเหตุการณ์ที่เกิดขึ้น
5. Serverless Architecture
Serverless ฟังดูเหมือนมีเวทมนตร์: ไม่มี Server มีแต่ Code ที่ทำงานอยู่บน Cloud!
แต่ในความเป็นจริง… Server ยังมีอยู่ เพียงแค่คุณไม่ต้องจัดการมันเองอีกต่อไป
ใน Serverless Architecture คุณจะเขียน Function เล็ก ๆ ที่ผู้ให้บริการ Cloud (เช่น AWS Lambda หรือ Azure Functions) จะรันตามคำสั่งหรือเหตุการณ์ที่เกิดขึ้น” คุณจ่ายเฉพาะเวลาที่ Function ทำงาน ไม่ต้องเสียเงินกับเวลาที่ Server ไม่ได้ใช้งาน
เมื่อ Serverless ทำงานได้ดี:
- App ที่มีปริมาณการใช้งานที่ไม่สามารถคาดเดาได้ (บางช่วงพุ่งสูง บางช่วงแทบไม่มีคนใช้)
- API ขนาดเล็ก, Background Jobs และ Automation Scripts
- Startups ที่ต้องการ MVPs โดยไม่ต้องมีต้นทุนโครงสร้างพื้นฐานขนาดใหญ่
จุดที่อาจสร้างความเสียหายได้:
- Cold starts = ต้องรอเวลาที่ Function ตื่นตัวก่อนทำงาน อาจทำให้รู้สึกหน่วงหรือช้าในตอนแรก
- การประสานงาน Application ที่ซับซ้อนจะทำได้ยาก หากคุณแยกออกเป็น Function เล็กๆ มากเกินไป
- Vendor lock-in: เปลี่ยนผู้ให้บริการ Cloud (AWS/GCP/Azure) ในภายหลังอาจยุ่งยากและต้องแก้ไข Code เยอะ
ตัวอย่างในโลกแห่งความเป็นจริง:
Netflix ใช้ Serverless สำหรับ Encoding แบบเรียลไทม์, การแจ้งเตือน User ตามเหตุการณ์ต่าง ๆ และการประมวลผลข้อมูล โดยเฉพาะเมื่อปริมาณงานเพิ่มขึ้นอย่างไม่คาดคิด
หมายเหตุ: Serverless ไม่ได้หมายความว่า ไม่มีการดูแลระบบ แต่หมายความว่า ให้คนอื่นเป็นคนดูแล (และแม้แต่คนอื่นก็ยังล้มเหลวบ้าง)
6. Hexagonal (Ports and Adapters) Architecture
Hexagonal Architecture ฟังดูซับซ้อน แต่จริง ๆ แล้วเป็นรูปแบบการออกแบบที่เป็นมิตรกับ Developer มากที่สุดแบบหนึ่ง
มีอีกชื่อว่า Ports and Adapters คือแนวคิดในการปกป้องตรรกะธุรกิจหลักของคุณ จากโลกภายนอกที่ซับซ้อน เช่น Databases, APIs และ UI Frameworks
ลองนึกภาพว่า App ของคุณคือปราสาท สิ่งสำคัญทั้งหมดเกิดขึ้นภายในกำแพง (Core Domain) และ Port (เหมือนประตู) และ Adapter (เหมือนสะพานชัก) ช่วยให้โลกภายนอกสื่อสารกับภายในได้ โดยไม่แตะตรรกะสำคัญโดยตรง
เมื่อ Hexagonal Architecture ทำงานได้ดี:
- Project ระยะยาวที่ต้องเจอกับการเปลี่ยนแปลงอย่างแน่นอน
- ระบบที่ต้องการความยืดหยุ่น เช่น เปลี่ยน Database หรือ API ได้โดยไม่ต้องปวดหัว
- ตรรกะทางธุรกิจที่สะอาดและทดสอบง่าย โดยไม่มีเสียงรบกวนจาก Code ภายนอก
จุดที่อาจสร้างความเสียหายได้:
- อาจจะเกินความจำเป็น สำหรับ App เล็ก ๆ หรือ Project ต้นแบบ
- ต้องมีวินัยในการเขียน Code และกำหนดขอบเขตชัดเจนตั้งแต่ต้น
ตัวอย่างในโลกแห่งความเป็นจริง:
Airbnb ใช้แนวทางที่คล้ายคลึงกับรูปแบบนี้ โดยปรับให้เหมาะกับระบบของ Airbnb เพื่อแยกระบบจอง การชำระเงิน และรายการที่พักออกจากกัน ทำให้สามารถพัฒนา Feature ใหม่ได้เร็วขึ้น โดยไม่กระทบกับกระบวนการหลักของระบบ
เคล็ดลับ: ถ้าคุณเบื่อกับการต้องเขียน Code ใหม่ทุกครั้ง เนื่องจากมีการเปลี่ยนแปลง API ภายนอก Hexagonal Architecture อาจกลายเป็นเพื่อนรักของคุณในอนาคตได้เลย
บทสรุป: เลือกอาวุธให้เหมาะกับศึกในแต่ละครั้ง
“ไม่มีรูปแบบ Architecture ไหนที่เหมาะกับทุกสถานการณ์”
ทั้ง 6 แบบ Monolith, Layered, Microservices, Event-Driven, Serverless, Hexagonal เป็นเพียงเครื่องมืออย่างหนึ่ง และเหมือนกับที่คุณไม่ควรใช้ขวานใหญ่ซ่อมนาฬิกา การเลือกให้เหมาะกับงานก็สำคัญพอ ๆ กับการลงมือทำ ดังนั้น เริ่มจากสิ่งที่เรียบง่าย แล้วค่อยปรับโครงสร้างเมื่อระบบใหญ่ขึ้น และอย่าลืมว่า: Architecture ที่ดีควรจะมองไม่เห็น โดย User ไม่รู้ว่ามันอยู่ตรงไหน แต่จะรู้สึกทันทีถ้ามันผิดพลาด
และทั้งหมดนี้ก็คือ 6 Software Architecture Patterns ที่ Developer ทุกคนควรรู้
เมื่อ หางาน IT ให้ ISM Technology Recruitment เป็นอีกหนึ่งตัวช่วย เพื่อให้คุณได้ “ชีวิตการทำงานในแบบที่คุณต้องการ” เพียงส่ง Resume มาที่นี่
ISM เชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ ได้เปิดทำการมาแล้วกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
Source: https://medium.com/devlink-tips/