เบื่อไหม? กับการแก้โค้ดฝั่งหนึ่งแล้วอีกฝั่งพัง! 😫

ในฐานะ Developer หลายคนคงเคยเจอปัญหาเรื่อง "โค้ดผูกติดกันแน่น" (Tight Coupling) จนจะแก้ Logic นิดเดียวแต่ต้องไล่แก้ทั้งโปรเจกต์ วันนี้ผมจะพามาทำความรู้จักกับทางสว่างที่เรียกว่า Clean Architecture ครับ

---

🏛 Clean Architecture คืออะไร?

Clean Architecture คือแนวคิดการออกแบบซอฟต์แวร์ที่ถูกนำเสนอโดย Uncle Bob (Robert C. Martin) โดยมีเป้าหมายหลักคือการแยก Business Logic ออกจาก Frameworks และ External Tools (เช่น Database, UI)

หัวใจสำคัญคือการแบ่งโค้ดออกเป็นชั้นๆ (Layers) เหมือนหัวหอม โดยมีกฎเหล็กที่เรียกว่า "Dependency Rule"

[!IMPORTANT] Dependency Rule: การเรียกใช้งาน (Dependency) ต้องชี้จาก "เลเยอร์นอก" เข้าหา "เลเยอร์ใน" เสมอ ชั้นข้างในห้ามรู้จักชั้นข้างนอกเด็ดขาด!

---

🧐 แกะกล่องแต่ละเลเยอร์ (The Circles)

หากเรามองจากในสุดออกมานอกสุด จะแบ่งได้ประมาณนี้ครับ:

1. Entities (หัวใจของระบบ)

บรรจุ Business Logic พื้นฐานที่สุด หรือ Model ข้อมูลของระบบ เช่น User, Product, Order เลเยอร์นี้เปลี่ยนน้อยที่สุดและไม่สนใจว่าโลกข้างนอกจะเป็นอย่างไร

2. Use Cases (Application Business Rules)

เลเยอร์นี้จะรวบรวม Logic ของแอปพลิเคชันว่า "จะทำอะไร" เช่น CreateUser, CalculateTotalAmount ซึ่งจะเป็นคนเรียกใช้ Entities อีกที

3. Interface Adapters (หน้าด่าน)

ทำหน้าที่แปลงข้อมูลระหว่างเลเยอร์ใน กับชั้นนอกสุด เช่น Controllers (รับ Request จากเว็บ), Presenters หรือ Gateways ที่ใช้คุยกับ Database

4. Frameworks & Drivers (ชั้นนอกสุด)

เป็นที่อยู่ของเครื่องมือต่างๆ ที่พร้อมจะเปลี่ยนได้เสมอ เช่น React, Next.js, MySQL, MongoDB, หรือพวก Third-party Library ทั้งหลาย

---

✅ ทำไมเราถึงต้องเหนื่อยทำ Clean Architecture?

1. Independent of Framework: คุณสามารถเปลี่ยนจาก React ไปใช้ Vue หรือเปลี่ยน DB จาก SQL เป็น NoSQL ได้โดยไม่ต้องแก้ Business Logic ใน Use Case เลย
2. Testable: เนื่องจาก Business Logic แยกตัวออกมาอิสระ ทำให้เราเขียน Unit Test ได้ง่ายมากโดยไม่ต้องรัน UI หรือ Database จริงๆ
3. Maintainability: เมื่อโค้ดแยกส่วนกันชัดเจน การหาบั๊กหรือเพิ่ม Feature ใหม่ก็ทำได้โดยไม่กระทบส่วนอื่น

---

💡 ตัวอย่างโค้ดสไตล์ Clean Architecture

ลองนึกภาพ Use Case ของการลงทะเบียน User ใหม่ดูครับ:

// Use Case: RegisterUser.ts
import { UserRepository } from '../repositories/UserRepository';
import { User } from '../entities/User';

export class RegisterUser {
  constructor(private userRepo: UserRepository) {}

  async execute(userData: any) {
    // 1. Business Logic
    const newUser = new User(userData.name, userData.email);
    
    // 2. Save to Data Storage (ผ่าน Interface/Contract)
    await this.userRepo.save(newUser);
    
    return newUser;
  }
}

สังเกตว่า RegisterUser ไม่รู้เลยว่า userRepo.save() จะไปเซฟลงไฟล์, ลง SQL หรือส่ง API ไปที่อื่น มันแค่ทำหน้าที่สั่งการตาม Logic เท่านั้น!

---

⚠️ เมื่อไหร่ที่ "ไม่ควร" ใช้?

แม้จะดูดี แต่ Clean Architecture ก็มีข้อเสียคือ "ความซับซ้อน" ครับ

• ถ้าแอปของคุณเป็นแค่แอปเล็กๆ หน้าเดียว (Simple Landing Page)
• หรือเป็นโปรเจกต์ที่ต้องรีบส่งด่วนและไม่มีความซับซ้อนของ Logic การใช้ Clean Architecture อาจกลายเป็นการ Over-engineering ที่ทำให้งานช้าลงโดยไม่จำเป็น

---

✨ สรุป

Clean Architecture ไม่ใช่กฎเหล็กที่ต้องทำตามเป๊ะๆ เสมอไป แต่มันคือ "แนวทาง" ที่ช่วยเตือนสติเราว่า อย่าให้ Framework หรือ Database มาชี้นิ้วสั่งโปรเจกต์ของเราครับ

ลองเอาไปปรับใช้ทีละนิด แล้วคุณจะพบว่าการแก้โค้ดไม่ได้น่ากลัวอย่างที่คิด!

ไว้เจอกันใหม่บทความหน้าครับ ขอให้สนุกกับการเขียนโค้ดที่สะอาดสะอ้านนะครับ! 🦆✨