オライリーのサブスクで「Domain-Driven Transformation: Modernize Legacy Systems and Mitigate Risk」のAI自動翻訳版、「ドメイン駆動型トランスフォーマー変換」が出ていた。非常に勉強になったので本の概要の紹介と感想を共有する。
本書について
DDDを学んだ後、既存システムをどうリファクタリングしていくべきかで迷うリーダーに向いた本である。DDDの概念説明はあるが、入門というより「DDDの知識をどう使うか」を具体的に示す構成である。架空の会社の事例が章ごとに用意されており、学んだ知見を現場の意思決定に落とし込むイメージがつく。結論として、本書は「DDDの実務的な適用手順」を知りたい人のためのガイドと言える。
本書で解説されているドメイン駆動型変換は、概ね以下の流れで進める。
- 技術的、戦術的、チーム組織的なドメイン駆動型変換
- 技術的安定性
- ドメイン知識でソースコードを強化する
- 組織変更
- 戦略的ドメイン駆動型変換
- ドメインの再発見
- ドメイン指向の目標アーキテクチャモデル
- 目標アーキテクチャと実アーキテクチャの整合
- 変換施策と優先順位づけと実装
以下、それぞれの狙いと要点をまとめる。
技術的、戦術的、チーム組織的なドメイン駆動型変換
戦略的分解に進む前に、基盤となるコードとチームの状態を整える段階である。ここを曖昧にしたまま戦略的再設計に進むと、実行不能な理想論になりやすい。
技術的安定性
開発環境やテスト戦略を見直し、変換の土台を固める。
- ライブラリやインフラ最新化
- CI/CDパイプラインの整備
- テスト戦略
- メトリクスを用いた内部構造の改善
- nullに対する防御で堅牢性向上
- assertによる前提のコード化
ドメイン知識でソースコードを強化する
ドメインモデルを表現力豊かにし、コードが業務の意味を語る状態に近づける。
- リポジトリパターンでビジネスロジックからデータベースクエリを分離する
- getter/setterしかない貧弱なロジックにドメイン言語や値オブジェクトを導入
- Design by Contract
組織変更
- 単一のドメイン専門領域に集中し反復的アプローチを取る小規模チームを作る
- チームトポロジーの考え方でチームが自律して活動可能にする
戦略的ドメイン駆動型変換
戦略的/戦術的DDDを使って、コードとアーキテクチャをドメイン駆動型に変換していく段階である。ここからが本書の核となる。
ドメインの再発見
ソースコードではなくビジネスプロセスから真の境界づけられたコンテキストを発見する。
- ドメイン専門家を巻き込んで現状把握
- ビジネスプロセスからドメインを抽出
- 業務プロセスを最適化し、あるべきプロセスへ
- 目標業務プロセスにおけるサブドメインの発見
ドメイン指向の目標アーキテクチャモデル
前ステップでモデル化したサブドメインから、ターゲットとなるコンテキストマップを導出する。
- サブドメインと将来のビジネスプロセスからターゲットコンテキストマップを導出する
- コンテキストマップ内の境界づけられたコンテキストを中核、支援、汎用のサブドメインに分類する
- 個々の境界づけられたコンテキストにチームを割り当てる
- 境界づけられたコンテキスト間のインタフェースを定義する
目標アーキテクチャと実アーキテクチャの整合
レガシーシステムを目標構想に整合させる。
- アーキテクチャ文書(C4文書)やツール(Sonargraph)を使って実際のアーキテクチャの特定
- 目標コンテキストマップとソースコードの比較
- リファクタリングと発見事項の決定
変換施策と優先順位づけと実装
どのリファクタリングに最初に取り組むか明確にし、テスト駆動で実装を進める。
- 最初の戦略的リファクタリングの選択
- 戦術的リファクタリングをプロダクトバックログまたは改善バックログに追加する
- 達成可能なリファクタリングをスプリントバックログに計画する
- コンテキストの抽出（リファクタリングの実行）
まとめ
DDDを学んだ後に「では既存システムはどう変えていくべきか」と悩むリーダーにとって、本書は具体的な道筋を示してくれる。技術基盤・コード・組織・戦略を一貫した流れで扱うため、現場での意思決定の軸が得られる点が良い。入門書の次に読む一冊として、特にチームを率いる立場の人に向いている。
