メインコンテンツまでスキップ

ADR-0001: ポート/アダプタパターンの採用

ステータス​

Accepted - 2024年採用

コンテキスト​

Bazbiiのバックエンドでは、ビジネスロジックとインフラストラクチャの実装を明確に分離する必要がありました。 以下の課題を解決する必要がありました：

  • テスタビリティ: ビジネスロジックを単体テストしやすくする
  • 変更への耐性: データベースや外部サービスを変更しても、ビジネスロジックに影響を与えない
  • 明確な境界: ドメインロジックと技術的詳細を分離し、コードの可読性を向上

決定​

ポート/アダプタパターン（Hexagonal Architecture）を採用し、以下の構造を実現しました：

server-core/          # ポート（インターフェース）
  ├── post/
  │   ├── ports.go    # リポジトリやサービスへのインターフェース定義
  │   └── service.go  # ビジネスロジック
  └── ...

server-platform/      # アダプタ（実装）
  └── datastore/
      └── postgres/   # PostgreSQL実装

実装方針​

  1. server-core: ビジネスロジックとドメインモデルのみ。外部依存なし
  2. server-platform: server-coreで定義されたインターフェースの実装
  3. 依存注入: server-appsでインターフェースと実装を組み合わせ

考慮した代替案​

代替案1: 伝統的な3層アーキテクチャ​

  • メリット: シンプルで理解しやすい
  • デメリット: ビジネスロジックとインフラが密結合になりやすい
  • 判断: テスタビリティと変更への耐性を優先し、却下

代替案2: DDDのリポジトリパターンのみ​

  • メリット: より軽量な実装
  • デメリット: 他の横断的関心事（認証、ログなど）も同様に抽象化する必要がある
  • 判断: ポート/アダプタで統一的な方針を採用

影響​

メリット​

  • ✅ テスタビリティ: server-coreのコードはモックを使ったテストが容易
  • ✅ 変更への耐性: データベースを変更しても、server-coreのコードは変更不要
  • ✅ 明確な境界: ドメインロジックと技術的詳細が明確に分離
  • ✅ 並行開発: インターフェースが決まれば、コアとプラットフォームの開発を並行可能

デメリット・課題​

  • ⚠️ コード量増加: インターフェースと実装の二重管理が必要
  • ⚠️ 学習コスト: 新規参加者はパターンを理解する必要がある
  • ⚠️ オーバーエンジニアリングのリスク: 単純な機能でもインターフェースが必要

今後の検討事項​

  • どの程度の粒度でポートを定義するか（リポジトリ単位 vs サービス単位）
  • 共通的な操作（CRUD）をどう抽象化するか

関連ADR​

  • なし（最初のADR）

参考​