ENGSE207 Software Architecture

Architectural Styles & Patterns

(Part 1: Fundamental Styles)

สัปดาห์ที่ 3 | เอกสารประกอบการสอน

หน่วยเรียน 1.1 – 1.3
Monolithic, Layered, Client-Server, N-Tier, Pipe-and-Filter

ผู้สอน: อ.ธนิต เกตุแก้ว
หลักสูตรวิศวกรรมซอฟต์แวร์ มทร.ล้านนา

🗺️ แผนที่การเดินทาง (Roadmap)

Week 1: Introduction

Week 2: Quality Attributes & Drivers

📍 Week 3: Fundamental Styles (วันนี้)

1.1 ภาพรวม Architectural Styles & Patterns
1.2 Monolithic & Layered Architecture
1.3 Client-Server, N-Tier, Pipe-and-Filter

Week 4: Modern Styles (Microservices, Serverless, Event-Driven, SOA)

🎯 วัตถุประสงค์การเรียนรู้ (CLOs)

สิ่งที่อยากให้นศ.ทำได้

อธิบายความแตกต่างระหว่าง Architectural Style และ Architectural Pattern ได้ (CLO2)
ระบุและอธิบาย Styles พื้นฐานอย่างน้อย 5 แบบได้ (Monolithic, Layered, Client-Server, N-Tier, Pipe-and-Filter)
เชื่อมโยง Quality Attributes กับการเลือกใช้ Style ที่เหมาะสมได้ (CLO6)

มุมวิเคราะห์และออกแบบ

วิเคราะห์ Architectural Drivers ที่สัมพันธ์กับ Styles ต่าง ๆ ได้ (CLO5)
เปรียบเทียบ trade-offs ของแต่ละ Style ในบริบทจริง เช่น LINE, Shopee, HIS (CLO7)
เตรียมโครงร่างสถาปัตยกรรมระดับสูงสำหรับโปรเจกต์ของตนเองได้

⏪ ทบทวนสัปดาห์ที่ 2

Quality Attributes: มาตรวัดคุณภาพระบบ คือ
Performance, Scalability, Security, Modifiability, Availability, Usability และอื่น ๆ

QA Scenario: โครงสร้างสถานการณ์ 6 ส่วน คือ
Source, Stimulus, Artifact, Environment, Response, Response Measure

Architectural Drivers: ปัจจัยหลักที่กำหนดสถาปัตยกรรม ได้แก่
Functional + Quality Attributes + Constraints + Assumptions

The Big Question for Week 3:

"เมื่อเรารู้ว่าระบบต้องการ Quality อะไร...
เราจะเลือกโครงสร้าง (Architectural Style) ไหนมาใช้?"

1.1 ภาพรวม Architectural Styles & Patterns

ความหมาย ความแตกต่าง และเหตุผลที่ต้องใช้

Architectural Styles คืออะไร?

Definition

โครงร่างแบบซ้ำได้ (Reusable) ของโครงสร้างระบบซอฟต์แวร์ในระดับสูง กำหนดรูปแบบของ Components, Connectors และ Constraints

มุมมอง

เน้น โครงสร้าง (Structure) และ ความสัมพันธ์ ระหว่าง Components
เป็น “ภาษากลาง” ระหว่างสถาปนิก–ทีมพัฒนา–ลูกค้า
เชื่อมโยงกับ Quality Attributes โดยตรง

Architectural Pattern คืออะไร?

Definition

โซลูชันที่พิสูจน์แล้วว่าใช้ได้ผล (Proven Solution) สำหรับปัญหาสถาปัตยกรรมที่เกิดขึ้นบ่อย มีโครงสร้างและแนวทางที่ค่อนข้างชัดเจน

ตัวอย่าง

MVC (Model–View–Controller)
Repository Pattern
Domain Events
CQRS, Event Sourcing (ในระบบใหญ่)

Style vs Pattern

Architectural Style

ภาพใหญ่ระดับระบบ (System Level)

"เราจะสร้างบ้านทรงไทย หรือทรงโมเดิร์น?"

Monolithic
Layered
Client-Server / N-Tier
Pipe-and-Filter, Microservices ฯลฯ

Architectural Pattern

วิธีแก้ปัญหาเฉพาะจุด (Component/Module Level)

"เราจะจัดห้องครัวอย่างไรให้ทำอาหารสะดวก?"

MVC (Model-View-Controller)
Repository Pattern
Domain Events, Event Sourcing

Architectural Styles ที่ควรรู้จัก

สัปดาห์นี้ (Week 3)

Monolithic Architecture
Layered (N-Tier) Architecture
Client-Server Architecture
N-Tier Architecture
Pipe-and-Filter Architecture

สัปดาห์หน้า (Week 4)

Microservices Architecture
Event-Driven Architecture
Service-Oriented Architecture (SOA)
Serverless Architecture
Hybrid Architectures

ระบบจริงมักเป็น Hybrid ผสมหลาย Styles เข้าด้วยกัน

💡 ทำไมต้องใช้ Architectural Styles?

1. ลดความซับซ้อน

ไม่ต้องเริ่มออกแบบจากศูนย์ ใช้แบบที่มีอยู่แล้ว

2. ภาษากลาง

พูดว่า "Layered" ทีมเข้าใจตรงกันทันที

3. ตัดสินใจเร็วขึ้น

ไม่ต้อง Reinvent the wheel

4. คุณภาพที่คาดการณ์ได้

รู้อยู่แล้วว่า Style นี้ดีต่อ Modifiability แต่อาจช้าลง

5. ลด Technical Risk

ใช้สถาปัตยกรรมที่มีคนใช้แล้วจำนวนมาก มี Best practices ให้ศึกษา

1.2 Monolithic & Layered Architecture

จุดเริ่มต้นของทุกสิ่ง

Monolithic Architecture

ลักษณะ

ระบบทั้งหมด Compile/Deploy เป็นก้อนเดียว
Codebase เดียว, Database หนึ่งชุด (โดยทั่วไป)
Module ต่าง ๆ เรียกกันตรง ๆ ผ่านฟังก์ชัน
เหมาะกับทีมเล็ก ฟีเจอร์ยังไม่เยอะ

ข้อควรระวัง

เมื่อระบบโตมาก ๆ จะ Refactor ยาก
Deploy ใหม่กระทบทั้งระบบ (Risk สูง)
Scaling ทำได้ทั้งก้อน (ไม่ยืดหยุ่น)
Technical Debt สะสมง่าย

🏢 โครงสร้าง Monolithic โดยภาพรวม

🏛️ Monolithic Architecture (Diagram)

แผนภาพตัวอย่าง Monolithic Application

Monolithic: Pros & Cons

✅ Pros

โครงสร้างง่าย เหมาะเริ่มต้น (Startup / MVP)
Debug ง่ายกว่าเพราะอยู่ใน Process เดียว
Transaction จัดการง่าย (DB เดียว)
Deploy ง่าย (ไฟล์เดียว / หน่วยเดียว)

⚠️ Cons

Deploy ช้าและเสี่ยงกระทบทั้งระบบ
ทีมใหญ่ทำงานพร้อมกันลำบาก (Conflict เยอะ)
Scalability จำกัด (ต้อง scale ทั้งก้อน)
Technology Lock-in (เปลี่ยน tech stack ยาก)

Monolithic: ใช้เมื่อไหร่ดี / ไม่ดี?

✅ เหมาะกับ

โปรเจกต์ขนาดเล็ก–กลาง, ทีม ≤ 10 คน
MVP / Proof of Concept ที่ต้องการ time-to-market เร็ว
Internal tools ภายในองค์กร

❌ ไม่เหมาะกับ

แอปที่ผู้ใช้จำนวนมาก ต้อง scale แบบยืดหยุ่น
ระบบที่ต้อง deploy บ่อยมาก ๆ (วันละหลายครั้ง)
ระบบที่ต้องการใช้เทคโนโลยีหลายแบบร่วมกัน

Case Study: Monolith ในโปรเจกต์จริง

🌱 โปรเจกต์ขนาดเล็ก–กลาง

ระบบ POS ร้านกาแฟ/ร้านอาหาร
หน้าขาย, จัดการเมนู, รายงานยอดขาย อยู่ในแอปเดียวกัน
ระบบจองคิวร้านตัดผม / คลินิกเล็ก
หน้าจอเดียวจัดการทั้งลูกค้า, คิว, แจ้งเตือน
Internal Tool ในบริษัท
ระบบเบิกของ, ระบบทำเรื่องเอกสารภายใน

👨‍💻 มุมมองสำหรับโปรเจกต์นักศึกษา

ทีม 3–5 คน, ระยะเวลา 1 เทอม → Monolith + Layered เพียงพอ
เน้นออกแบบโครงสร้างโค้ดให้ดี (แยก Controller / Service / Repository)
ถ้าจะต่อยอดในอนาคต ค่อยคิดเรื่องแยกเป็น Service ภายหลัง

💡 ข้อคิด: "เริ่มให้เดินได้ก่อน (Monolith) แล้วค่อยคิดเรื่องวิ่งมาราธอน (Microservices)"

🏛️ Layered (N-Tier) Architecture

แผนภาพตัวอย่าง Layered (3-Tier) Architecture

หลักการ: Separation of Concerns

แบ่งระบบเป็นชั้น แต่ละชั้นคุยกับชั้นที่ติดกันเท่านั้น

1. Presentation Layer (UI): รับ Input, แสดงผล (React, HTML)

2. Business Logic Layer: กฎทางธุรกิจ, คำนวณ (Service Classes)

3. Data Access Layer (DAL): คุยกับ Database (Repositories, ORM)

Dependency Rule: Layer บนเรียก Layer ล่างได้ แต่ล่างห้ามเรียกดึงบน

🔍 Deep Dive: 3-Tier vs. 4-Tier

Standard 3-Tier (แบบที่เห็นบ่อย)


Browser / App
   |   
   | HTTP
   ↓  
Web / App Server
   |
   | SQL 
   ↓    
Database

ใน Web / App Server เดียวกันมีทั้ง Controller, Business Logic, Data Access ปนกัน
คิดง่าย ๆ ว่าเป็น Monolith ที่แบ่งไฟล์เป็นเลเยอร์ (UI / Logic / DB)
เปลี่ยนกฎธุรกิจบ่อย ๆ จะไปแก้ที่ Service เดียวกันหลายอย่าง

Extended 4-Tier (แนวคิด Clean Architecture)


UI (Controller)
   |
   ↓
Application Layer (Use Cases)
   |
   ↓
Domain Layer (Entities + Rules)
   |
   ↓
Infrastructure (DB, External API)

แยก Use Case (ลำดับขั้นตอนงาน) ออกจาก Domain Rules (กฎของธุรกิจ)
Domain ไม่รู้เรื่อง Framework หรือ Database → เปลี่ยนเทคโนโลยีง่ายขึ้น
เป็นพื้นฐานไปสู่ Clean / Hexagonal Architecture ในอนาคต

ตัวอย่าง: ระบบลงทะเบียนเรียน
(3-Tier vs 4-Tier)

3-Tier

นักศึกษากดเลือกวิชาในหน้าเว็บ
Controller เรียก Service ตัวหนึ่งที่ทั้งตรวจสอบและบันทึกข้อมูล
Service ดึงข้อมูลจาก Database ผ่าน Repository
กฎเช่น “ไม่เกิน 22 หน่วยกิต” เขียนปนอยู่ใน Service นี้เลย

โครงสร้างทำงานได้ แต่กฎธุรกิจกระจาย/ปนกับโค้ดควบคุมลำดับงาน → ทดสอบยาก

4-Tier

นักศึกษากดเลือกวิชาในหน้าเว็บ (UI)
Controller เรียก RegisterCourseUseCase ใน Application Layer
Use Case ใช้ Domain Model Student / Course ตรวจสอบว่า ตรงตามกฎทุกข้อหรือไม่ (หน่วยกิต, เงื่อนไข, เวลาเรียนชน ฯลฯ)
ถ้าผ่านแล้ว ค่อยเรียก Repository ใน Infrastructure เพื่อบันทึกลง Database

กฎธุรกิจหลักจะอยู่ใน Domain → ทดสอบได้ง่าย, ใช้ซ้ำได้ทั้ง Web, Mobile, API อื่น ๆ

Layered Architecture: Pros & Cons

Pros

Maintainability สูง (แยกส่วนชัดเจน)
Test ง่าย (Mock Layer ล่างได้)
รองรับทีมใหญ่ แบ่งทีมตาม Layer ได้
แยก UI หลายแบบใช้ Business Layer เดียวกัน

Cons

ถ้าออกแบบไม่ดีจะกลายเป็น "Layered Monolith" ที่หนาแน่น
Cross-cutting Concerns (Logging, Security) จัดการยากถ้าไม่มี Pattern เสริม
เพิ่ม latency จากการผ่านหลาย Layers

Case Study: Layered + N-Tier ใน Web App

🏫 ระบบลงทะเบียนเรียนมหาวิทยาลัย

Presentation: Web Portal นักศึกษา / อาจารย์
Application: ตรวจสอบเงื่อนไขวิชา, เวลาเรียนชนกัน
Domain/Data: เก็บข้อมูลนักศึกษา, วิชา, ตารางสอน

🏥 Hospital Information System

UI: หน้าจอหมอ, พยาบาล, แผนกการเงิน
Business: การนัดหมาย, เวชระเบียน, คิดค่ารักษา
Data: ตารางผู้ป่วย, ตารางนัด, ตารางยาที่จ่าย

🏦 Internet Banking

UI: Mobile Banking / Web Banking
Application: ตรวจ Limit, กฎการโอนเงิน, OTP
Data: Account DB, Transaction DB

สังเกตว่า: โครงสร้างในโค้ด (Layer) มักจะ Map ตรงกับการ Deploy จริง (Tier) ในระบบขนาดใหญ่

1.3 Client-Server, N-Tier & Pipe-Filter

โครงสร้างยอดนิยมในระบบจริง

🖥️ Client-Server: แนวคิดพื้นฐาน

Client ส่ง Request → Server ประมวลผลและส่ง Response กลับ
Server เป็นศูนย์กลางของ Business Logic และ Data
รองรับผู้ใช้หลายคน (Multi-client) พร้อมกัน
ทำงานแบบ Stateless (HTTP/REST) หรือ Stateful (WebSocket, FTP) ก็ได้

🖥️ Client-Server Architecture (Diagram)

ผู้ขอใช้บริการ (Client) ↔ ผู้ให้บริการ (Server)

รูปแบบของ Client-Server

2-Tier

Client (Thick) + DB Server
Logic อยู่ที่ Client
เหมาะกับ Desktop Apps เก่าๆ, ระบบเล็กภายใน

3-Tier (Web)

Client (Thin/Browser)
App Server (Logic)
DB Server (Data)
ใช้ใน Web Apps ส่วนใหญ่ในปัจจุบัน

Concept Check: Stateless vs. Stateful

Stateless (REST/HTTP)
Server ไม่จำ Client
"ทุก Request คือคนแปลกหน้า"

Stateful (WebSocket/FTP)
Server จำ Session ได้
"คุยต่อเนื่อง ไม่ต้องแนะนำตัวใหม่"

🏗️ N-Tier Architecture (Diagram)

Note: Tier = Physical Separation (เครื่องคนละเครื่อง)

N-Tier: ใช้เมื่อไหร่?

✅ ข้อดี

Scale แต่ละ Tier แยกกันได้ (เช่น เพิ่ม App Server อย่างเดียว)
Security ดีขึ้น จัด Zone ได้หลายชั้น (DMZ / App / DB)
ยืดหยุ่น เปลี่ยน Tech ในบาง Tier ได้

⚠️ ข้อเสีย

Infrastructure ซับซ้อน ต้องมีหลาย Servers/Services
Debug / Monitoring ยากขึ้น
Latency เพิ่มขึ้น เพราะผ่านหลายชั้น

🔧 Pipe-Filter Architecture (Diagram)

เหมาะกับงานที่เป็นลำดับขั้นตอนชัดเจน เช่น ETL, Image Processing, Audio Processing

Pipe-Filter: แนวคิดหลัก

Filter = Component ที่แปลง/ประมวลผลข้อมูล
Pipe = ช่องทางส่งข้อมูลระหว่าง Filters
แต่ละ Filter ทำงานได้อิสระ สามารถ reuse และจัดเรียงใหม่ได้


Input → [Filter 1] → [Filter 2] → [Filter 3] → Output

ตัวอย่าง: Log → Parse → Filter ERROR → Aggregate → Alert

ตัวอย่าง Pipe-Filter (Node.js Stream)


const fs = require('fs');
const zlib = require('zlib');

// Read → Compress → Write
fs.createReadStream('input.log')
  .pipe(zlib.createGzip())      // Filter 1: บีบอัด
  .pipe(fs.createWriteStream('input.log.gz')); // Filter 2: เขียนไฟล์ใหม่

console.log('Done!');

Reusable & Composable!

Case Study: Pipe-Filter ใน Data Pipeline จริง

🧾 ระบบวิเคราะห์ Log (Log Analytics)

Collect: รวม Log จากหลาย Server
Filter: ตัดเฉพาะ ERROR / WARNING
Transform: แปลงรูปแบบเป็น JSON มาตรฐาน
Aggregate: รวมตาม Service / เวลา
Alert: ถ้า Error เกิน Threshold → ส่งแจ้งเตือน

แต่ละขั้นสามารถเป็น Filter ตัวหนึ่ง ต่อเชื่อมด้วย Pipe (Message Queue / Stream)

📦 Data Engineering / ETL

Extract: ดึงข้อมูลดิบจากหลายแหล่ง (DB, CSV, API)
Clean: ลบ Record ซ้ำ, แก้ค่าที่ผิดพลาด
Enrich: เติมข้อมูลจากตารางอื่น (Join)
Load: นำเข้า Data Warehouse / Data Lake

แต่ละขั้นเป็น Filter แยกกัน ทำให้ re-use pipeline เดิมได้กับหลายโปรเจกต์

การเปรียบเทียบและกรณีศึกษา

เลือกอย่างไรให้เหมาะสม?

📊 Comparison Summary

🤔 เลือก Style ไหนดี?
(Decision Framework)

1. ขนาดระบบ?
เล็ก → Monolith / Simple Layered | ใหญ่ → N-Tier / Microservices

2. จำนวนผู้ใช้?
น้อย → Monolith | เยอะ → N-Tier (Scale ได้)

3. ประเภทงาน?
ประมวลผลข้อมูล → Pipe-Filter | Interactive → Client-Server

4. Time to Market?
รีบมาก → Monolith

📱 Case Study: LINE Messaging

Architecture: Client-Server + N-Tier + Microservices (บางส่วน)

Client: Mobile App (Android/iOS)
Protocol: HTTP/2, WebSocket (Real-time)
Backend: แยก Service ตามหน้าที่ (User, Sticker, Message)

Key Drivers:
⚡ Performance (ต้องเร็ว)
📈 Scalability (คนใช้ล้านคน)
🔒 Availability (ต้องพร้อมใช้งานตลอดเวลา)

🛒 Case Study: Shopee / Lazada

Architecture: N-Tier / Microservices

มี CDN เก็บรูปภาพสินค้า
API Gateway จัดการ Request
Backend แยก Service: Product, Order, Payment, Recommendation

Key Drivers:
🔒 Reliability (เงินต้องตรง, Order ต้องถูกต้อง)
📈 Scalability (Flash Sale, Campaign 11.11)

🏥 Case Study: Hospital Information System (ไทย)

Architecture: Layered + N-Tier

UI: หน้าจอหมอ, พยาบาล, แผนกการเงิน, ห้องยา
Business Layer: Appointment, Billing, Medical Records
Data Layer: Patient DB, Appointment DB, Pharmacy DB

Quality Attributes สำคัญ:

🔒 Security & Privacy – ข้อมูลผู้ป่วยต้องปลอดภัย
🔄 Reliability – ระบบต้องไม่ล่มระหว่างการรักษา
📝 Auditability – ต้องตรวจสอบประวัติการเข้าถึงข้อมูลได้

🧠 Quick Quiz: Test Your Understanding

ตอบคำถามสั้น ๆ เพื่อลองเช็คความเข้าใจเรื่อง Styles วันนี้

Q1: สตาร์ทอัพทีมเล็ก ต้องการสร้างแอปฯ รีบปล่อยตลาด (MVP) ควรใช้ Style ใด?

A. Microservices Architecture

B. Pipe-and-Filter Architecture

C. Monolithic Architecture

เฉลย: Monolithic เริ่มต้นง่ายสุด Setup เร็ว ไม่ซับซ้อน เหมาะกับทีมเล็กและ MVP

Q2: ข้อใดคือความแตกต่างหลักระหว่าง Layer และ Tier?

A. Layer ใช้กับ Database, Tier ใช้กับ Code

B. Layer คือ Logical, Tier คือ Physical

C. เหมือนกัน ใช้แทนกันได้เลย

เฉลย: Layer แบ่งตามโครงสร้างในโค้ด ส่วน Tier แบ่งตามการ Deploy บนเครื่อง/Server

❓ คำถามท้ายบท (Self-check)

Architectural Style และ Architectural Pattern ต่างกันอย่างไร? ยกตัวอย่างประกอบ
Monolithic Architecture เหมาะกับโปรเจกต์แบบไหน? และไม่เหมาะกับแบบไหน?
อธิบายแนวคิด Separation of Concerns ใน Layered Architecture
เปรียบเทียบ 2-Tier กับ 3-Tier Architecture ว่าต่างกันอย่างไร
Pipe-and-Filter Architecture เหมาะกับงานประเภทใดในโลกจริง?
ถ้าให้เลือกสถาปัตยกรรมสำหรับระบบ E-Commerce จะเลือกแบบใด เพราะอะไร?
Trade-offs สำคัญระหว่าง Monolithic กับ N-Tier/Distributed Architecture คืออะไร?

💡 สามารถใช้คำถามเหล่านี้ทบทวนก่อนสอบ หรือใช้เป็น Guideline ออกแบบโปรเจกต์ของตัวเองได้

สรุปและสิ่งที่ต้องจำ

🔑 Key Takeaways

Architectural Styles คือเครื่องมือ ไม่ใช่กฎตายตัว เลือกใช้ตาม Context
ไม่มี "Perfect Architecture" ทุกอย่างคือ Trade-offs (ได้อย่างเสียอย่าง)
Quality Attributes เป็นตัวกำหนด Style ที่ควรเลือก
เริ่มต้นจาก Simple (Monolith/Layered) แล้วค่อยขยายเมื่อจำเป็น

บทสรุปสำหรับสัปดาห์นี้

Simple is Good

Monolithic ไม่ใช่ผู้ร้าย ถ้าระบบไม่ใหญ่ มันคือพระเอก

Structure Matters

Layered ช่วยให้โค้ดสะอาด รักษาได้ยาวนาน

Distribution Costs

Client-Server/N-Tier ดีแต่แลกมาด้วยความซับซ้อนของ Network และ Infrastructure

Pipeline Thinking

คิดแบบท่อ (Pipe) เมื่อต้อง process ข้อมูลเป็นขั้นตอนตามลำดับ

🔜 สัปดาห์หน้า (Part 2)

เราจะเข้าสู่ Modern Architecture:

Microservices Architecture

Event-Driven Architecture

Serverless

Service-Oriented (SOA)

เตรียมตัว: ลองหาข้อมูล Netflix Architecture มาล่วงหน้า

Q & A

มีคำถามไหมครับ?

"Good architecture is not about making decisions early,
but delaying them until you have more information."
- Robert C. Martin

ENGSE207 Software Architecture

Architectural Styles & Patterns

(Part 1: Fundamental Styles)

🗺️ แผนที่การเดินทาง (Roadmap)

🎯 วัตถุประสงค์การเรียนรู้ (CLOs)

สิ่งที่อยากให้นศ.ทำได้

มุมวิเคราะห์และออกแบบ

⏪ ทบทวนสัปดาห์ที่ 2

The Big Question for Week 3:

1.1 ภาพรวม Architectural Styles & Patterns

Architectural Styles คืออะไร?

Definition

มุมมอง

Architectural Pattern คืออะไร?

Definition

ตัวอย่าง

Style vs Pattern

Architectural Style

Architectural Pattern

Architectural Styles ที่ควรรู้จัก

สัปดาห์นี้ (Week 3)

สัปดาห์หน้า (Week 4)

💡 ทำไมต้องใช้ Architectural Styles?

1. ลดความซับซ้อน

2. ภาษากลาง

3. ตัดสินใจเร็วขึ้น

4. คุณภาพที่คาดการณ์ได้

5. ลด Technical Risk

1.2 Monolithic & Layered Architecture

Monolithic Architecture

ลักษณะ

ข้อควรระวัง

🏢 โครงสร้าง Monolithic โดยภาพรวม

🏛️ Monolithic Architecture (Diagram)

Monolithic: Pros & Cons

✅ Pros

⚠️ Cons

Monolithic: ใช้เมื่อไหร่ดี / ไม่ดี?

✅ เหมาะกับ

❌ ไม่เหมาะกับ

Case Study: Monolith ในโปรเจกต์จริง

🌱 โปรเจกต์ขนาดเล็ก–กลาง

👨‍💻 มุมมองสำหรับโปรเจกต์นักศึกษา

🏛️ Layered (N-Tier) Architecture

หลักการ: Separation of Concerns

🔍 Deep Dive: 3-Tier vs. 4-Tier

Standard 3-Tier (แบบที่เห็นบ่อย)

Extended 4-Tier (แนวคิด Clean Architecture)

ตัวอย่าง: ระบบลงทะเบียนเรียน (3-Tier vs 4-Tier)

3-Tier

4-Tier

Layered Architecture: Pros & Cons

Pros

Cons

Case Study: Layered + N-Tier ใน Web App

🏫 ระบบลงทะเบียนเรียนมหาวิทยาลัย

🏥 Hospital Information System

🏦 Internet Banking

1.3 Client-Server, N-Tier & Pipe-Filter

🖥️ Client-Server: แนวคิดพื้นฐาน

🖥️ Client-Server Architecture (Diagram)

รูปแบบของ Client-Server

2-Tier

3-Tier (Web)

Concept Check: Stateless vs. Stateful

🏗️ N-Tier Architecture (Diagram)

N-Tier: ใช้เมื่อไหร่?

✅ ข้อดี

⚠️ ข้อเสีย

🔧 Pipe-Filter Architecture (Diagram)

Pipe-Filter: แนวคิดหลัก

ตัวอย่าง Pipe-Filter (Node.js Stream)

Case Study: Pipe-Filter ใน Data Pipeline จริง

🧾 ระบบวิเคราะห์ Log (Log Analytics)

📦 Data Engineering / ETL

การเปรียบเทียบและกรณีศึกษา

📊 Comparison Summary

🤔 เลือก Style ไหนดี? (Decision Framework)

📱 Case Study: LINE Messaging

🛒 Case Study: Shopee / Lazada

ตัวอย่าง: ระบบลงทะเบียนเรียน
(3-Tier vs 4-Tier)

🤔 เลือก Style ไหนดี?
(Decision Framework)