Interface-Oriented Design: รากฐานของ Clean Architecture

บทนำ

หนึ่งในความท้าทายสำคัญของซอฟต์แวร์ยุคใหม่ คือการออกแบบระบบให้ยืดหยุ่น ดูแลง่าย และพร้อมรับการเปลี่ยนแปลง
Clean Architecture เป็นแนวทางยอดนิยมที่ช่วยให้บรรลุเป้าหมายนี้
แต่เบื้องหลังความสำเร็จของ Clean Architecture ก็คือหลักคิดสำคัญที่เรียกว่า
Interface-Oriented Design (IOD)

Interface-Oriented Design คืออะไร?

IOD คือ การออกแบบระบบโดยให้แต่ละส่วนสื่อสารกันผ่าน “interface” หรือ “สัญญา” (contract) แทนที่จะขึ้นกับ implementation จริง
ทุก dependency ที่ business logic ต้องการ จะถูกกำหนดเป็น interface ก่อนเสมอ
Implementation ต่าง ๆ (เช่น ฐานข้อมูล, ระบบอีเมล, Payment Gateway) จะมา “เสียบ” ที่ interface เหล่านี้ทีหลัง
ผลลัพธ์คือระบบที่เปลี่ยนส่วนย่อยได้ง่าย และทดสอบได้สะดวก

Clean Architecture คืออะไร?

Clean Architecture (โดย Robert C. Martin หรือ Uncle Bob) แบ่งระบบออกเป็นชั้น (layers) ชัดเจน:

Core Layer: กติกาทางธุรกิจล้วน ๆ (business rules) ไม่มีการผูกกับเทคโนโลยี
Interface Layer: กำหนดขอบเขตและสัญญา (contract) เช่น Repository, Gateway
Infrastructure Layer: Implementation จริง (เช่น MySQL, Stripe, REST API) ที่มา implement interface จาก layer กลาง

กฎสำคัญ:

Dependency ทุกตัวต้องชี้เข้าใน (inward dependencies)
Layer นอกสุดจะขึ้นกับ Layer ในสุดเท่านั้น ไม่ใช่ในทางกลับกัน

ทำไม IOD คือ DNA ของ Clean Architecture

Clean Architecture จะบังคับให้ business logic “ไม่ผูก” กับรายละเอียดภายนอก เช่น Framework, Database
แต่จะทำได้จริงก็ต่อเมื่อเรา “ใช้ interface” เป็นตัวกลาง
ถ้าไม่ใช้ IOD ระบบจะถูกผูกกับ implementation โดยตรง และเสียข้อดีของ Clean Architecture ไป

แผนภาพ Mermaid.js: ความสัมพันธ์ของ IOD กับ Clean Architecture

flowchart TD
    subgraph OuterLayer [Framework/Infrastructure Layer]
        A["Web Controller"]
        B["Database Adapter"]
        C["Payment Adapter"]
    end
    subgraph Interfaces
        D["OrderRepository (interface)"]
        E["PaymentGateway (interface)"]
    end
    subgraph Core [Business Logic / Use Case]
        F["OrderService"]
        G["PaymentService"]
    end

    A --> D
    B --> D
    C --> E
    F --> D
    G --> E

คำอธิบายแผนภาพ:

OuterLayer: ตัวอย่างเช่น Web Controller, Adapter ของฐานข้อมูล หรือ Payment
Interfaces Layer: คือข้อตกลงหรือ interface ต่าง ๆ (เช่น OrderRepository, PaymentGateway)
Core Layer: กติกาทางธุรกิจ เช่น การสั่งซื้อ การจ่ายเงิน ซึ่งจะขึ้นกับ interface เท่านั้น ไม่รู้จักหรือขึ้นกับ implementation จริง

ตัวอย่างที่นำไปใช้จริง

เช่น หากคุณต้องการบันทึกออเดอร์และจ่ายเงินใน core logic

# ใน core/business logic
class OrderRepository(ABC):
    @abstractmethod
    def save(self, order): ...

class PaymentGateway(ABC):
    @abstractmethod
    def pay(self, amount): ...

class OrderService:
    def __init__(self, order_repo: OrderRepository, payment_gateway: PaymentGateway):
        self.order_repo = order_repo
        self.payment_gateway = payment_gateway

    def place_order(self, order, payment_amount):
        self.order_repo.save(order)
        self.payment_gateway.pay(payment_amount)

ส่วน implementation จะอยู่ layer นอก

class MySQLOrderRepository(OrderRepository):
    def save(self, order): 
        # รายละเอียดการบันทึกออเดอร์

class StripeGateway(PaymentGateway):
    def pay(self, amount): 
        # รายละเอียดการชำระเงิน

คุณสามารถเปลี่ยนไปใช้ MongoDB, PostgreSQL, หรือ gateway ใหม่ได้โดยไม่แตะต้อง business logic
ทดสอบ business logic ได้ง่ายมากด้วย mock/fake implementation

สรุปประโยชน์

ยืดหยุ่น: เปลี่ยนเทคโนโลยีได้โดยไม่กระทบแกนหลัก
ทดสอบง่าย: Mock dependency ได้อย่างสบาย
ดูแลง่าย: ไม่ผูกกับ framework หรือเทคโนโลยีเฉพาะ

สรุปท้ายบท

Interface-Oriented Design คือเทคนิคหลักที่อยู่เบื้องหลังความสำเร็จของ Clean Architecture
ถ้าเริ่มจากการวาง interface ให้ชัดในทุกขอบเขต ระบบของคุณจะคลีน ทดสอบง่าย และรองรับการเปลี่ยนแปลงได้อย่างแท้จริง