今回は O’Reilly のサブスクで読める Domain-Driven Transformation という本を読んだので、
その本の感想と学びを書きたいと思います。
この本は、DDD の設計解説がメインではなく、
システムを“壊さずに”どのように変革していくか にフォーカスした内容です。
🔄 システム刷新がうまくいかなくなる理由
システム刷新をどう進めるかを考えるとき、
振り返ってみると、失敗しやすいパターンにはいくつか共通点があるように感じます。
- 先に「理想のアーキテクチャ」だけを決めてしまう
- 現場の業務理解が追いついていない
- チーム構成が旧システム前提のまま
- 「完成後に一気に切り替える」前提で進めてしまう
結果として、
技術だけを置き換えようとして、
ビジネスと組織が置き去りになる
という状態になりがちです。
多くのシステム刷新がうまくいかないときの、典型的なパターンのひとつではないかと思います。
この本では、まさにこうした落とし穴を避けるための
考え方と進め方が、具体的に解説されていました。
🔧 この本が扱っているのは「設計」ではなく「変革」
「技術だけを置き換えてしまい、ビジネスや組織が置き去りになる」という失敗を避けるために、
本書では 最初からシステムを“変革”として捉える という立場を取っています。
その象徴が、常に次の 3 つを セットで扱っている 点でした。
- ビジネス
- ソフトウェアアーキテクチャ
- チーム・組織構造
どれか 1 つだけを先に変えてしまうと、必ずどこかで歪みが生まれます。
だからこそこの本では、
「3 つを同時に、少しずつ動かし続ける」 という考え方を一貫して語っていたのが、とても印象的でした。
🗣️ 変革の出発点は「コード」ではなく「業務」
この本では、変革の第一歩として
業務そのものをあらためて見つめ直すこと が強く強調されていました。
たとえば、
- このシステムは、どんな業務の流れを支えているのか
- どんなイベントが日々発生しているのか
- 人が悩んでいるポイントはどこか
- 属人化している判断はどこか
といったことを、関係者同士の「会話」を通して明らかにしていく、
いわゆる 会話ベースのモデリング が重要だとされています。
「暗黙知を可視化すること自体が、すでに変革の第一歩である」
という考え方が強調されており、とても良かったです。
🧱 いきなりマイクロサービスにしない
技術的な進め方として印象的だったのは、
「まずモノリスの中身をきちんとモジュール化する」というメッセージでした。
この本では、モノリシックな「大きな泥団子（Big Ball of Mud）」を、
そのまま複数のデプロイメントユニットに分割してしまうと、
「分散された大きな泥団子（distributed Big Ball of Mud）」 になってしまう、と警告しています。
- まず 業務単位（ドメイン単位）で境界を明確にし、モノリスをモジュール化する
- そのうえで、必要に応じて一部の境界づけられたコンテキストを
独立したデプロイメント（マイクロサービス）として切り出していく - ロジックと責務の分割ができていれば、「どこにデプロイするか」はいつでも変えられる
つまり、いきなりマイクロサービスに移行するのではなく、
まず「モジュラーモノリス」として健全な構造に育ててから分散させていく、
という道筋が強調されているのが印象的でした。
🧩 リファクタリングは「コード」だけじゃない
この本がより実戦向きだと感じたのは、次の 3 種類の「リファクタリング」を
どれも同じくらい重要なものとして扱っているように思えた部分があったからです。
- 技術的リファクタリング
- 戦略的リファクタリング
- 社会技術的リファクタリング（組織・人）
つまり、
- チーム構成を変えるのもリファクタリング
- 責任分担を変えるのもリファクタリング
- 意思決定フローを変えるのもリファクタリング
と捉えている、ということです。
「コードだけをきれいにすれば全て解決するわけではない」という現場のリアルを、
かなり正面から扱っている本だな、という印象を受けました。
ここについてはドメイン駆動リファクタリングとして
著者がサイトで詳しくまとめています
🪜 壊さずに進める 4 ステップの変革プロセス
この本の中心にあるのが、
システムを一気に作り替えるのではなく、少しずつ安全に刷新していくための 4 ステップ です。
すでに運用されているシステムでは、
- 業務プロセスの変化
- 回避策としての運用
- Excel や手作業などのシャドーIT
といったものも含めて「今の姿」になっています。
この本では、そうした現実を前提にした刷新の進め方 が整理されています。
その上で、変革は次の 4 ステップで進めていくと説明されています。
Step1：ドメインの再発見
まずはコードではなく、
「このシステムは本来どんな業務を支えているのか」 を見つめ直すところから始まります。
Step2：ターゲットアーキテクチャの設計
再発見したドメインをもとに、
将来目指す構造（境界づけられたコンテキスト）を描く フェーズです。
Step3：現状とのギャップの可視化
理想の構造と、今のシステムのズレを整理する ステップです。
ここで初めて、どこから手を付けるべきかが見えてきます。
Step4：優先順位をつけて段階的に実行
一気に置き換えず、できるところから少しずつ進めていく フェーズです。
ここで一貫しているのは、
「正しさ」よりも「進め続けられること」を優先する
という姿勢でした。
この 4 ステップは、「どこから手を付ければいいか分からない」状態から抜け出すための、実践的な指針 になると感じました。
✅ まとめ
この本は、
DDD は「きれいな設計」を作るためのものではなく、「壊さずに進化し続けるための技術」なのだ
と改めて感じさせてくれる一冊でした。
レガシーシステムには多くの業務知識が詰まっており、
簡単に捨てて作り直せるものではありません。
だからこそ、止めずに、安全に、意図的に進化させていく という考え方がとても現実的だと感じました。
こういった 泥臭くも前に進めるための思考と技法は、
特定の技術スタックに依存しない、大切な技術だと思います。
Domain-Driven Transformation は、
そのための 実践的なロードマップを示してくれる一冊 だと感じました。
とても面白い本でしたが、ブラウザ翻訳で読んだため解釈が怪しい部分もありました 💦
日本語訳版が出たら、ぜひ読み直したいと思います。
Discussion