『ドメイン駆動トランスフォーメーション』の要点を理解する ―「ドメインって何？」から始める、レガシー再生の教科書
オライリー・ジャパン『ドメイン駆動トランスフォーメーション ―レガシーシステムのモダナイゼーションとリスク低減』(2026年6月刊、456ページ) の核となる考え方と、現場でやらかしがちなアンチパターンを整理する。
対象読者
この記事は次のような人に向けて書いている。
- 古いシステムを抱えていて、どうにかしたいと思っている人
- DDDは聞いたことあるけど、何がそんなにいいのかピンと来てない人
- 「マイクロサービス化する」と決まったが、何から始めればいいかわからない人
- 「全部書き直そう」という話が出ていて、不安を感じている人
- チームをまとめる立場で、モダナイゼーションの判断材料が欲しい人
DDDの予備知識はいらない。「ドメインって何？」から順に積み上げて説明する。
そもそも「ドメイン」って何？
ドメインとは、ソフトウェアが扱う対象の世界 のこと。
ECサイトを作るなら、扱う世界は「買い物」だ。
- 商品がある
- カートに入れる
- 注文する
- 配送される
- お金を払う
この一かたまりが、ECサイトの「ドメイン」。
銀行アプリなら、ドメインは「銀行業務」。
- 口座がある
- 振込する
- 残高を見る
- ローンを組む
ゲームならドメインは「ゲームの世界」。キャラクター、戦闘、アイテム、レベルアップ。
つまりドメインとは、「そのソフトウェアを使う人たちが普段やっている仕事や活動の世界」 のことだ。
なぜ「ドメイン駆動」なのか
ソフトウェア設計には、大きく2つのスタイルがある。
スタイルA: 技術中心の設計
技術スタックでまず分ける。Web層、ビジネス層、DB層。各層に各業務の関心事が横断的に散らばる。
スタイルB: ドメイン中心の設計（＝DDD）
業務単位でまず分ける。注文・商品・カート・決済が、それぞれ自分のUI〜DBまで縦に持つ。
なぜBがいいのか
ビジネスは変わる。でも、変わり方は業務の単位で変わる。
「注文の仕様が変わる」とき、Bなら「注文」モジュールだけ触ればいい。
Aだと、UI・ロジック・DBの3層すべてに手を入れることになる。
ドメイン中心に設計すれば、変更が業務単位で閉じる。これがDDDの一番の御利益だ。
DDDで覚えるのは3つだけでいい
DDDは概念が多くて挫折しがち。でも本書を読む準備としては、3つだけ押さえれば十分。
① ユビキタス言語 ― 業務担当者と開発者が同じ言葉を使う
業務担当者が「注文」と呼ぶものは、コードでも Order と書く。
業務担当者が「カート」と呼ぶものは、コードでも Cart と書く。
ShoppingBag とか OrderEntity とか勝手な命名はしない。
これだけ。シンプルだけど効果は絶大で、認識ズレによるバグが激減する。
② 境界づけられたコンテキスト ― 同じ言葉でも文脈で意味が変わる
「顧客」という言葉、銀行業務ではコンテキストごとに意味が違う。
- 融資チーム から見ると → 信用情報を持つ存在
- 振込チーム から見ると → 口座を持つ存在
-
マーケチーム から見ると → メアドを持つ存在
これを全部1つのCustomerクラスにすると、巨大化して誰も触れなくなる。
コンテキストごとに別の Customer クラスにする ― これが境界づけられたコンテキスト（Bounded Context）の発想。
③ サブドメインの3分類 ― どこに力を入れるか決める
ドメインの中身を3種類に分ける。
| 種類 | 意味 | 対応 |
|---|---|---|
| コアサブドメイン | 会社の差別化要因 | ここに全力投入。自社で作る |
| 支援サブドメイン | 必要だけど差別化しない | 普通に作る |
| 汎用サブドメイン | どこの会社にもある（認証、メール送信など） | 既製品を買う |
例えばECサイトなら、レコメンドエンジンはコア、商品管理は支援、決済は汎用。
すべてのサブドメインに同じ力を入れるのは無駄だ、という考え方。
ここまで理解できれば、本書を読む準備は完了。
じゃあ「ドメイン駆動トランスフォーメーション」って何？
ここからが本題。
DDDは「これから作る新しいソフトウェア」をどう設計するかの話だった。
でも現実には、すでに動いている20年もののモノリス を抱えている会社のほうが圧倒的に多い。
このグチャグチャになったコードベース（大きな泥団子 / Big Ball of Mud と呼ぶ）をDDDの世界へ持っていくにはどうすればいいのか?
それを4ステップで体系化したのが、本書「ドメイン駆動トランスフォーメーション(DDT)」 だ。
つまり整理すると:
| 名前 | 何の話か |
|---|---|
| DDD（ドメイン駆動設計） | 新規開発でドメイン中心に設計する思想 |
| DDT（ドメイン駆動トランスフォーメーション） | 既存のレガシーシステムをDDDの世界へ移行する手順 |
DDTの中核: 4ステップ手法
本書の本体はこの4ステップに集約される。
1つずつ見ていく。
ステップ1: ドメイン再発見
やること: 業務担当者と一緒に「今のビジネスはどうなっているか」を書き出す。
ここで一番大事なのは、コードを読まないこと。
レガシーシステムのコードは、過去のビジネス理解が固まったもの。今のビジネスとはズレている可能性が高い。だから、いったんコードを横に置いて、現在のビジネスを再発見する。
使う手法はこの2つが代表的:
| 手法 | やること |
|---|---|
| ドメインストーリーテリング | 業務フローを「誰が」「何を」「どうした」の矢印付き図で描く |
| イベントストーミング | 「何が起きた」を付箋で時系列に並べる |
ステップ2: ターゲットアーキテクチャ
やること: 再発見したドメインから「あるべき姿」を設計する。
ドメインを境界づけられたコンテキストに分割する。
各コンテキストには:
- どのチームが担当するか
- 他コンテキストとどう連携するか
- コンテキスト内のモデル（クラス設計）
を決めていく。これが「ターゲットコンテキストマップ」。
ステップ3: 現状とのすり合わせ
やること: 現状コードを可視化して、ターゲットとの差分を出す。
アーキテクチャ可視化ツールを使う:
- Sonargraph
- Structure101
- TeamScale
- Lattix
- JQAssistant
これらで現状の依存関係を見える化し、ターゲットコンテキストマップを重ねる。
ここで必ず見つかる課題が、後述する 無境界モデル系のアンチパターン。
ステップ4: 優先順位付けと実施
やること: リファクタリング項目を1スプリントで終わる粒度に分割し、新機能開発と並行して実施する。
ここでの鉄則:
本書のケーススタディでは「作業量の30%をモダナイゼーションに充てる」例が紹介されている。新機能開発を止めずに進めるのがポイント。
MMI ― 自分のシステムを採点する
本書のもう1つの目玉が MMI（モジュール性成熟度インデックス）。
0〜10のスコアで現状を測る。スコアによって取るべきパスが変わる。
「ウチのシステムは何から始めるべきか」に再現性のある答えを出せる、これがMMIの価値だ。
本書の地図 ― 何が書いてあるか
本書は「導入 + 4部 + リファクタリングカタログ」の構成。
導入（1章）
コンテナターミナルの実例で4ステップを駆け足体験する章。ここだけ読んでも本書のメッセージの7割は伝わる。
第Ⅰ部 基礎（2〜6章）
DDD・モデリング・アーキテクチャの前提知識。
| 章 | テーマ |
|---|---|
| 2 | 複雑性を制する |
| 3 | ドメイン駆動設計 |
| 4 | 協働モデリング（ドメインストーリーテリング・イベントストーミング） |
| 5 | アーキテクチャの概念（モノリス・マイクロサービス・MMI） |
| 6 | アプローチ方法（ビッグバン vs 段階置換 vs リシェイピング） |
6章は地雷回避のために必読。後述するアンチパターン1位の根拠がここ。
第Ⅱ部 技術的・戦術的・チーム組織的トランスフォーメーション（7〜9章）
レガシーを内側から強化する3つの観点。
| 章 | テーマ |
|---|---|
| 7 | 技術的トランスフォーメーション（テスト整備・リファクタリング） |
| 8 | ドメイン知識でソースコードを強化する |
| 9 | チーム構造（チームトポロジー） |
第Ⅲ部 戦略的ドメイン駆動トランスフォーメーション（10〜13章）
本書の 本体。4ステップ手法の詳細解説。
| 章 | ステップ |
|---|---|
| 10 | ステップ1: ドメイン再発見 |
| 11 | ステップ2: ターゲットアーキテクチャ |
| 12 | ステップ3: 現状とのすり合わせ |
| 13 | ステップ4: 優先順位付けと実施 |
12章はアンチパターンと処方箋の宝庫。
第Ⅳ部 総括（14〜15章）
ドメインパターン（パイプライン・ブラックボード・ダイアログ）と全体まとめ。
付録 リファクタリングカタログ（A〜E）
本書独自の 武器庫。すぐ使える具体的な手順カタログ。
| 付録 | 用途 |
|---|---|
| B | 戦略的リファクタリング（モノリスをコンテキストに分割） |
| C | 戦術的リファクタリング（戦略的を支える小ステップ） |
| D | 社会技術的リファクタリング（チーム再編） |
| E | ドメイン知識を強化する戦術的リファクタリング |
現場で必ずやらかすアンチパターン ベスト5
ここからが実践編。本書を読んだ上で「これを避けないと必ず失敗する」と感じた5つを、やらかしやすさ × 被害の大きさ で順位付けした。
🥇 第1位: ビッグバン置換に飛びつく
症状: 「もう限界だ、全部書き直そう」と全社合意し、新システムをゼロから作り始める。旧システムはフリーズして塩漬けに。
なぜ起きるか: 経営陣には「全部新しくする」のほうが説明しやすい。開発者は新技術で書きたい。「リファクタリングしながら稼働」は地味でROIが見えにくい。
何が起こるか:
対策: ストラングラーフィグ（Strangler Fig）パターンを使う。
新システムが旧システムに少しずつ絡みつき、機能を1つずつ置き換えて、最後に旧システムを停止する。Martin Fowlerが提唱した手法。
本書6章は「ビッグバンが有効なケースは実際にはほとんどない」と断言している。第一選択肢にすべきはステップバイステップ置換だ。
🥈 第2位: コードから着手してドメイン再発見をスキップ
症状: 「まずコードを読んで、依存関係を整理しよう」とソースコード分析から始める。アーキテクトと開発者だけで議論が完結する。
なぜ起きるか: エンジニアにとってコードは慣れた領域。業務担当者と話すのは不慣れ。「ドメインを再発見する」という発想自体が新しい。
何が問題か:
レガシーコードは過去のビジネス理解が固まったもの。それを整理しても「過去の誤解」が綺麗に並ぶだけだ。
対策: ステップ1（ドメイン再発見）を必ず最初にやる。
コードから始めるな、人と話せ。これが本書の最重要メッセージの1つ。
🥉 第3位: 「再利用性」の名で巨大ドメインモデルを温存
症状: Customer Product Contract といった巨大クラスがある。新機能を追加するたびにメソッドとフィールドが増えていく。「Productに関することは1か所を見ればわかる」状態を「再利用」と呼んでいる。
なぜ起きるか: 既存クラスを拡張するのはDRY原則に従っているように見える。学校や入門書で「再利用は善」と教わってきた。
実際に起こること:
各UIが必要なものは違うのに、全員が同じ巨大クラスを共有している。1人が変更するだけで他全員に影響する地獄。
対策: コンテキストごとにクラスを分ける。
同じ Customer でも、コンテキストごとに別物として扱う。「再利用」と思っていたものは、実は「異なる業務概念の混在」だった。
本書12.5節「課題: 無境界ドメインモデル」と「12.5.1 問題の原因: 再利用性の誤解」が真正面から扱うテーマ。
第4位: アーキテクチャだけ変えてチーム構造を変えない
症状: コードは境界づけられたコンテキストで分割した。でもチームは「フロントエンドチーム」「バックエンドチーム」「DBチーム」のレイヤー構成のまま。コンテキストAの変更にも全チームの調整が必要。
なぜ起きるか: 組織変更は政治的コストが高い。「コードだけ直せばいい」と思いがち。
何が問題か:
サービスが分かれていても、変更には全チームの合意が必要。**「マイクロサービスを始めたら逆に開発が遅くなった」**現象の正体はこれ。
対策: チームトポロジーの「ストリームアラインドチーム」に再編する。
1つの境界づけられたコンテキスト = 1つのチーム = フロント〜DBまで縦に責任を持つ。
これがコンウェイの法則の正しい使い方。本書9章で詳細に解説されている。付録Dには「レイヤーチームをクロスファンクショナルチームへ段階的に再編する具体的手順」が載っている。
第5位: 全部を一度に完璧にやろうとする
症状: 「どうせやるなら徹底的に」と、全コンテキストを一度に切り出そうとする。あるいは「貧血モデルも値オブジェクトも全部直したい」と要件を盛りすぎる。半年でプロジェクトが頓挫する。
なぜ起きるか: 完璧主義。「中途半端な状態が一番危険」という思い込み。ステークホルダーに「全部やります」と約束してしまう。
何が問題か:
対策: 1スプリントで完了する粒度まで分割する。
新機能開発も並行する。本書のケーススタディでは 「作業量の30%をモダナイゼーションに充てる」 進め方が紹介されている。
| ❌ アンチパターン | ⭕ 本書推奨 |
|---|---|
| 全コンテキストを一度に切り出す | 1コンテキストずつ |
| 完璧なモデルを最初に設計 | 戦略的→戦術的の順で段階的に |
| トランスフォーメーション専任プロジェクト | 新機能開発と並行（30%ルール） |
| 全部の貧血モデルを一斉解消 | 抽出済みコンテキスト内で順次 |
まとめ
ここまでを5行で要約すると:
- ドメインとは、ソフトウェアが扱う業務領域のこと
- DDDは、その業務領域を中心にソフトウェアを設計する考え方
- DDTは、DDDをレガシーシステムに適用する4ステップ手法
- コードから始めるな、ドメインから始めろ
- ビッグバンは禁忌、ストラングラーフィグで段階置換
最後まで見てくれてありがとうございます！
あなたのいいねが励みになります！
参考文献
本書
- 書名: ドメイン駆動トランスフォーメーション ―レガシーシステムのモダナイゼーションとリスク低減
- 原書: Domain-Driven Transformation: Modernize Legacy Systems and Mitigate Risk
- 著者: Carola Lilienthal, Henning Schwentner
- 序文: Michael Feathers（『Working Effectively with Legacy Code』著者）
- 出版: オライリー・ジャパン