🙌

『Architecture for Flow』第4章を読む：Tactical DDDでドメインモデルを実装する

に公開
DDD
architecture
Software Design
idea

「戦略をコードへ。ドメインモデルを中心に据える。」

Susanne Kaiser の『Architecture for Flow』第4章を読み、戦術的DDD（Tactical Domain-Driven Design）とPorts and Adaptersアーキテクチャによる実装アプローチを整理しました。

🎯 目的 ― ドメインモデルをコードとして実装する

第3章では、 Bounded Context を用いてソリューション空間を設計し、ビジネス戦略をアーキテクチャへと落とし込みました。

第4章では、いよいよその設計を コードとして実現する段階 に入ります。
ここで登場するのが、 戦術的ドメイン駆動設計（Tactical DDD: 戦術的DDD） です。

著者はこの章で、「ドメインモデルはシステムの心臓部であり、外部技術に依存せず進化できるように設計すべき」 と強調しています。

🧱 戦術的DDDのビルディングブロック

戦術的DDDは、ドメインモデルを構築するための具体的なパターン群 を提供します。
これらの要素を組み合わせることで、ビジネスロジックを明確に分離し、
外部依存に引きずられない堅牢なモデルを実現します。

要素 説明 役割
エンティティ（Entity） 一意の識別子（ID）とライフサイクルを持ち、状態を随時変更できるオブジェクト。 ビジネス上の主要な概念を表す。
値オブジェクト（Value Object） 不変で、値そのものによって同一性を判断する。変更時は新しいインスタンスを生成。 計算や属性など、値ベースの概念を表現。
集約（Aggregate） 1つ以上のエンティティと値オブジェクトの集合体。トランザクション境界を形成。 一貫性の単位。整合性を保つための“塊”。
集約ルート（Aggregate Root） 集約の代表オブジェクト。外部からの唯一の入り口となる。 集約内の整合性を保証。
ドメインサービス（Domain Service） どのエンティティにも属さないビジネスロジックを担当。 ルールや処理を分離し、モデルを整理。
ドメインイベント（Domain Event） モデル内で起こる重要な出来事を表現。 状態変化の伝達・非同期処理に利用。

🔄 Ports and Adaptersアーキテクチャとの統合

戦術的DDDの強みを最大化するために、本章では Ports and Adaptersアーキテクチャ（ヘキサゴナルアーキテクチャ） の導入が解説されています。

● アーキテクチャの目的

Ports and Adaptersは、 アプリケーションのビジネスロジックを外部環境から隔離すること を目的とします。

これにより、UI・DB・メッセージングなどの周辺技術が変わっても、コアとなるドメインロジックは影響を受けません。

[外部世界]  
↓ ↑  
[Adapters] ←→ [Ports] ←→ [ドメインモデル（Core）]

アプリケーションの「内側」にあるのがドメインモデルであり、「外側」にはUI、API、DB、メッセージブローカーなどが存在します。
PortsとAdaptersを介することで、両者を疎結合に保ちます。

⚙️ ドメインモデルを中心に据える実装構造

● アプリケーションサービス（Application Service）

  • トランザクション管理、セキュリティ、ログなど横断的関心を扱う。
  • ドメインモデルにアクセスするための ドライビングポート（入力側のポート） の役割を担う。
  • ドメインモデル自体のロジックは含めない。

● リポジトリ（Repository）

  • 集約やエンティティを永続化／取得するためのインターフェース。
  • リポジトリの定義は ドリブンポート（出力側のポート） 、その実装が ドリブンアダプター となる。
  • インフラ技術（DBやORM）を抽象化し、ドメインモデルを独立させる。

● ドメインモデルの独立性

ドメインモデルは、永続化・API・UIといった技術的関心から完全に切り離されます。
これにより、変化しやすい外部要素（たとえばフレームワークのバージョン）と独立して、ドメインロジックを長期的に進化させられる構造が実現します。

🧩 DDD × Ports and Adapters ― 両者の関係性

領域 目的 対応するDDD要素
ドメイン層（Domain Layer） ビジネスロジックの中心。外部依存なし。 エンティティ、値オブジェクト、集約、ドメインサービス、イベント
アプリケーション層（Application Layer） トランザクション、セキュリティ、調整。 アプリケーションサービス
インフラ層（Infrastructure Layer） 外部システムや技術統合を扱う。 リポジトリ実装、アダプター、メッセージングなど

🧠 戦術的DDDがもたらす適応性

著者は本章で、戦術的DDDの目的を次のように定義しています：

「ドメインモデルを技術的関心から切り離し、独立して進化できるようにすること。」

これにより、

  • 外部技術や統合方式の変更に柔軟に対応できる。
  • テスト容易性が向上し、ビジネスロジックの検証が容易になる。
  • アーキテクチャの“内核（Core）”を長期的に保守・拡張できる。

つまり、戦術的DDDは「コードのレベルでアダプティブなシステムを作るための設計思想」です。

🌱 学びのまとめ

第4章の要点を一文でまとめるなら、こうです。

「ドメインモデルを中心に、技術的詳細から切り離して設計せよ。」

  • 戦術的DDDは、エンティティ／値オブジェクト／集約などの実装指針を提供する。
  • Ports and Adaptersアーキテクチャと組み合わせることで、
    ドメインロジックを外部環境から隔離できる。
  • この分離が、システムを 独立して進化可能な構造（Evolvable Architecture） に導く。

🧩 次回予告 ― チーム構造とフローを一致させる

次章では、**Team Topologies（チームトポロジー）**の観点から、
Bounded Contextやドメインモデルを実装するチームの構造と責務を見ていきます。

📘 関連リソース

🪶 “Keep the domain model at the core, independent from external change.”
— Susanne Kaiser, Architecture for Flow

Discussion