All Insights

Clean Architecture 101

Clean Architecture ฉบับเข้าใจง่าย

Clean Architecture 101: เริ่มต้นจาก “แก่น” ไม่ใช่ “โฟลเดอร์”

ถ้าคุณเคยเริ่มโปรเจกต์ใหม่แล้วติดอยู่กับคำถามว่า
“ต้องตั้งโฟลเดอร์ยังไงถึงจะเป็น Clean Architecture?”

คุณกำลังโฟกัสผิดจุดตั้งแต่ต้น

Clean Architecture ไม่ได้เริ่มจากการจัดโครงสร้างไฟล์ แต่มันเริ่มจาก “วิธีคิด” ในการออกแบบระบบ

Clean Architecture คืออะไร (แบบไม่ขายฝัน)

แนวคิดนี้ถูกเสนอโดย Robert C. Martin (Uncle Bob)
โดยมีเป้าหมายชัดเจนมาก:

ทำให้ Business Logic (แก่นของระบบ)
ไม่ผูกติดกับ Framework, Database, หรือ Technology ใด ๆ

ผลลัพธ์คือ:

  • เปลี่ยน DB ได้ โดยไม่ต้อง rewrite ทั้งระบบ
  • เปลี่ยน Framework ได้ โดย logic ยังอยู่ครบ
  • เขียน test ได้ง่าย เพราะ logic ไม่พึ่งของภายนอก

ความเข้าใจผิดยอดฮิต: “Clean Architecture = Folder Structure”

นี่คือคำถามที่เจอบ่อยมาก:

  • โฟลเดอร์ต้องชื่อ use-cases หรือ services?
  • use case ควรอยู่ใต้ domain หรือ application?
  • ใช้ Hexagonal หรือ Onion ดี?

คำตอบสั้น ๆ:

ไม่มีโครงสร้างไหน “ถูกต้อง” สำหรับ Clean Architecture

แก่นจริง ๆ คือ “ทิศทางของ Dependency”

Clean Architecture สนใจแค่สิ่งเดียว:

Dependency ต้อง “ชี้เข้าด้านใน” เสมอ

นั่นหมายความว่า:

  • Core Business Logic ต้องไม่รู้จักโลกภายนอก
  • แต่โลกภายนอกสามารถเรียกเข้ามาหา Core ได้

แนวคิดจากโพสต์ Facebook (ที่ควรจำให้ขึ้นใจ)

❓ Project Structure แบบไหนที่ถูกต้อง สำหรับ Clean Architecture?
ตอบสั้นๆ ง่ายๆ: ไม่มี

เพราะหัวใจของ Clean Architecture ไม่ใช่การจัด folder แต่คือการควบคุม “ทิศทางของ dependency”

คำถามยอดฮิตที่มักจะโผล่มาตลอด คือ
👉 โฟลเดอร์ต้องชื่อ use cases หรือ services?
👉 use cases ต้องอยู่ใต้ domain หรือ application?
👉 จะเอา structure แบบ hexagonal หรือ onion ดี?

❌ Clean Architecture ไม่ได้บอกให้คุณใช้ folder structure แบบไหนเลย
✅ เพราะแนวคิดหลักของ Clean Architecture คือการควบคุม dependency ให้ชี้เข้าด้านในเพื่อแยก business logic ออกจากพวก technology ภายนอกทั้งหมด

เราสามารถเขียนทุกอย่างไว้ในไฟล์เดียวก็ Clean ได้ ถ้า:

  • ไม่มี domain objects เช่น entity หรือ use case ไหนรู้จัก database, external API, หรือ message broker โดยตรง
  • Dependency ทุกอย่างชี้เข้าหา core business logic เสมอ

Layer ที่เราพูดถึงใน Clean Architecture ไม่ใช่ folder แต่มันคือแนวคิดในเรื่องของ boundary ที่จำกัดขอบเขตความรับผิดชอบของ component ต่างๆ เช่น

  • Entities จัดการกับ critical business rules เช่น ไม่สามารถโอนเงินเกินจำนวนยอดเงินคงเหลือได้
  • Use Cases → คุม flow และ orchestrate domain logic เช่น หลังจากสร้างบัญชีเงินฝากแล้วต้องส่งข้อมูลไปตรวจสอบกับระบบ KYC
  • Interface Adapters → แปลงข้อมูลจากโลกภายนอกให้ใช้ได้กับ business rules ของเรา
  • Frameworks & Drivers → Database Client, Kafka Client, SDKs ต่างๆ

ดังนั้น
การจัด folder structure เป็นเรื่องของ convention ที่ทีมควรตกลงร่วมกัน เพื่อให้โค้ดเข้าใจง่าย ทำงานร่วมกันได้สะดวก

สิ่งที่สำคัญยิ่งกว่าคือ “Awareness” หรือความเข้าใจว่าโค้ดที่เรากำลังเขียนอยู่ มันมีหน้าที่อะไร และอยู่ใน layer ไหนของระบบ

  • ถ้าคุณกำลังเขียน use case → ห้ามไปเรียก Database Client โดยตรง
  • ถ้าคุณอยู่ใน domain → ห้ามรู้จัก HTTP, SQL, หรือ SDK ใด ๆ ทั้งสิ้น
  • ถ้าคุณเขียน adapter → คุณ จะ รู้จัก MySQL, Kafka, Express ได้เต็มที่เพราะนั่นคือพื้นที่ของมัน

สรุปอีกที
Clean Architecture คือแนวคิดการออกแบบระบบที่ทำให้ business logic ไม่ผูกติดกับ technology หรือ framework ใด ๆ ทดสอบได้ง่าย เปลี่ยน technology ได้โดยไม่ต้องรื้อระบบ

และที่สำคัญที่สุด มันไม่ใช่เรื่องของ project structure

แล้ว “Layer” คืออะไร (ถ้าไม่ใช่โฟลเดอร์)?

Layer ใน Clean Architecture คือ “ขอบเขตความรับผิดชอบ” (Boundary) ไม่ใช่ directory

1. Entities (Core Business Rules)

  • กฎธุรกิจที่สำคัญที่สุด
  • เช่น: “ห้ามโอนเงินเกินยอดคงเหลือ”

2. Use Cases (Application Logic)

  • จัด flow ของระบบ
  • orchestrate domain logic
  • เช่น: เปิดบัญชี → ตรวจ KYC → ส่ง notification

3. Interface Adapters

  • แปลงข้อมูลจากโลกภายนอก
  • เช่น Controller, Presenter, Repository implementation

4. Frameworks & Drivers

  • สิ่งที่ “เปลี่ยนได้ง่าย”
  • เช่น DB, Kafka, HTTP framework

ตัวอย่าง mindset ที่ถูกต้อง

แทนที่จะถามว่า:

“โฟลเดอร์นี้ควรชื่ออะไร?”

ให้ถามว่า:

  • “โค้ดนี้เป็น business rule หรือเปล่า?”
  • “มันควรรู้จัก database ไหม?”
  • “มันอยู่ boundary ไหน?”

Practical Rule (เอาไปใช้ได้ทันที)

  • ถ้าเขียน Domain / Entity → ห้าม import อะไรจาก infra
  • ถ้าเขียน Use Case → ห้ามยิง DB หรือ call API ตรง
  • ถ้าเขียน Adapter → จะใช้ MySQL, Kafka, Express เต็มที่ก็ได้

สรุปแบบตรงไปตรงมา

Clean Architecture ไม่ใช่:

  • โฟลเดอร์สวย ๆ
  • naming convention เท่ ๆ
  • diagram วงกลม ๆ

มันคือ:

“วินัยในการควบคุม dependency เพื่อปกป้อง business logic”

และถ้าคุณเข้าใจสิ่งนี้จริง
ต่อให้โค้ดอยู่ในไฟล์เดียว
มันก็ยัง Clean ได้

ถ้าคุณกำลังจะเริ่มใช้ Clean Architecture ในโปรเจกต์ใหม่
อย่าเริ่มที่โฟลเดอร์

เริ่มที่ “การแยกความรับผิดชอบ” และ “ทิศทางของ dependency”