Interface-Oriented Design:クリーンアーキテクチャの基礎

はじめに

現代のソフトウェア設計では、「変更に強く、保守しやすく、拡張可能」であることが重要です。
クリーンアーキテクチャ(Clean Architecture) は、その実現手法として広く使われています。
しかし、その力の源は「Interface-Oriented Design(インターフェース指向設計)」という考え方にあります。


Interface-Oriented Designとは?

  • IOD とは、「実装(implementation)」ではなく「インターフェース(interface)」を介して各部品がやり取りする設計思想です。
  • ビジネスロジックが必要とする依存先は、必ずインターフェースで定義します。
  • 実際の実装(例:データベース、メール送信、決済サービス)は、このインターフェースを実装(implement)する形で外側に追加されます。
  • 結果として、システムの各部分を簡単に差し替え・テストできる柔軟な設計が実現します。

クリーンアーキテクチャとは?

クリーンアーキテクチャ(ロバート・C・マーチン、通称Uncle Bob提唱)は、システムを明確なレイヤーで構成します。

  • コアレイヤー(Core Layer):
    ビジネスルール(ビジネスロジック)のみ。技術詳細に依存しない。
  • インターフェースレイヤー(Interface Layer):
    各種「契約」(インターフェース、リポジトリ、ゲートウェイ等)を定義。
  • インフラストラクチャレイヤー(Infrastructure Layer):
    実装クラス(例:MySQLリポジトリ、Stripe決済APIクライアント等)がインターフェースを実装。

最も重要なルール:

すべての依存関係は内側(コア)に向かう
外側のレイヤーは内側に依存するが、逆はない


なぜIODがクリーンアーキテクチャの「DNA」なのか?

クリーンアーキテクチャでは、ビジネスロジックがフレームワークやDBといった「詳細実装」に依存しないことが求められます。
そのための「仕組み」がインターフェース指向設計(IOD)です。
もしインターフェースを使わなければ、コアは容易に実装に依存してしまい、アーキテクチャのメリットが失われます。


Mermaid.js 図解:クリーンアーキテクチャとIODの関係

flowchart TD
    subgraph OuterLayer [フレームワーク/インフラストラクチャ層]
        A["Webコントローラー"]
        B["DBアダプター"]
        C["決済アダプター"]
    end
    subgraph Interfaces
        D["OrderRepository (インターフェース)"]
        E["PaymentGateway (インターフェース)"]
    end
    subgraph Core [ビジネスロジック / ユースケース]
        F["OrderService"]
        G["PaymentService"]
    end

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

図解説明:

  • OuterLayer: Webコントローラー、DBアダプター、決済アダプターなど技術的な詳細
  • Interfaces Layer: OrderRepository、PaymentGatewayなどのインターフェース(契約)
  • Core Layer: ビジネスロジック。インターフェースにのみ依存し、実装には依存しない

実践例

たとえば、注文保存と決済処理をコアロジックで行いたい場合:

# コア(ビジネスロジック側)
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)

インフラストラクチャ層で実装を用意:

class MySQLOrderRepository(OrderRepository):
    def save(self, order): 
        # 実装詳細

class StripeGateway(PaymentGateway):
    def pay(self, amount): 
        # 実装詳細
  • MySQLをMongoDBや別DBに変える場合も、ビジネスロジックには手を加えなくて良い
  • テスト時もモックやフェイク実装で容易に検証可能

主なメリット

  • 柔軟性: 技術や実装変更が容易
  • テスト容易性: コアロジックを独立してテストできる
  • 保守性: 技術的負債や依存性を最小化

まとめ

Interface-Oriented Designは、クリーンアーキテクチャの強さを生み出す土台となるテクニックです。
まずインターフェースで各レイヤーを明確に切り分けることで、システムの核(コア)はどんな時代の技術にも対応できる柔軟性と堅牢さを持ち続けます。


Get in Touch with us

Chat with Us on LINE

iiitum1984

Speak to Us or Whatsapp

(+66) 83001 0222

Related Posts

Our Products