ドメイン駆動トランスフォーメーション

―レガシーシステムのモダナイゼーションとリスク低減

[cover photo]
TOPICS
System/Network
発行年月日
PRINT LENGTH
456
ISBN
978-4-8144-0172-7
原書
Domain-Driven Transformation
FORMAT
Print
Print
5,280円

本書は、老朽化した大規模なレガシーシステムを、マイクロサービスや保守性の高いモジュラーモノリスへと再生させるための実践的なガイドです。ドメイン駆動設計(DDD)を軸に、戦略、技術、組織という三つの視点から、アーキテクチャの劣化が進んだソフトウェアを刷新するアプローチを提示しています。ビジネスプロセスの分析を通じて境界づけられたコンテキストを特定し、アジャイルチーム内でドメイン駆動リファクタリングを適用する方法を学びます。また、モジュール性の健全度を測る指標を用いた現状分析や、チームトポロジーによる組織編成、イベントストーミングを用いた設計の可視化など、具体的なツールや技法も詳述しています。リスクを抑えながら段階的に改善を進めるためのパターンや、豊富な実例に基づいた知見が凝縮された本書は、長期にわたって強靭性を維持できるシステムを構築するための指針となる一冊です。

目次

まえがき

1章 導入:ドメイン駆動トランスフォーメーションの全体像
    1.1 事例:コンテナ港のレガシーシステム
        1.1.1 ドメイン再発見
        1.1.2 ターゲットアーキテクチャの決定
        1.1.3 現状のアーキテクチャとターゲットアーキテクチャの比較
        1.1.4 トランスフォーメーションの優先順位づけと実施
        1.1.5 何が起こったのか
    1.2 手法
        1.2.1 ドメイン駆動トランスフォーメーションのパス
    1.3 まとめ

第I部 基礎

2章 複雑性を制する
    2.1 複雑性の発生要因:問題空間と解決空間
    2.2 複雑性の種別:本質的複雑性と偶発的複雑性
        2.2.1 偶発的複雑性の要因
        2.2.2 ソフトウェアアーキテクチャの意思決定領域
        2.2.3 本質的複雑性と偶発的複雑性への対処
    2.3 レガシーシステムにおける複雑性
    2.4 基礎となるメソッド
    2.5 次章では

3章 ドメイン駆動設計
    3.1 複雑性に立ち向かうDDDの概念
    3.2 DDDとビジネスドメイン
        3.2.1 ユビキタス言語
        3.2.2 ビジネス側の戦略的設計
        3.2.3 サブドメインの分類:何がコアか? 
    3.3 DDDとソフトウェアソリューション
        3.3.1 ソフトウェアにおける戦略的設計
        3.3.2 コンテキストマッピング
        3.3.3 バブルコンテキスト
        3.3.4 ドメインモデル
        3.3.5 DDDにおける階層アーキテクチャ
        3.3.6 戦術的設計
        3.3.7 ドメインイベント
    3.4 まとめ

4章 協働モデリング
    4.1 モデリングツールとモデル独占
    4.2 トランスフォーメーションのための協働モデリング手法
    4.3 適切な人々を集める
    4.4 協働モデリングの基本概念
    4.5 協働モデリングとDDD 
    4.6 ドメインストーリーテリング
        4.6.1 1 つの図1 つのストーリー
        4.6.2 境界の引き方
        4.6.3 ドメインストーリーのスコープファクター
        4.6.4 ドメインモデルの発見
        4.6.5 発展
    4.7 イベントストーミング
        4.7.1 ビッグピクチャーイベントストーミングによる探索
        4.7.2 カオス探索
        4.7.3 タイムラインの適用
        4.7.4 人とシステム
        4.7.5 明示的ウォークスルー
        4.7.6 付加価値ステップ
        4.7.7 境界の描き方
        4.7.8 カラーコーディング
        4.7.9 詳細への深掘り:ソフトウェアデザインイベントストーミング
        4.7.10 ドメインモデルの発見
        4.7.11 その他の形式と発展
    4.8 シナリオキャスティング
        4.8.1 この手法はどのように機能するか? 
        4.8.2 コアアイデア
        4.8.3 ワークショップの流れ:探索から実装へ
        4.8.4 ケーススタディの紹介:Green Urban Supplier 
        4.8.5 ステップ1:ブレインストーミング
        4.8.6 ステップ2:フォーカスの特定
        4.8.7 ステップ3:組み立て
        4.8.8 シナリオベースアプローチの次のステップは? 
        4.8.9 シナリオキャスティングの第2 ラウンド
        4.8.10 発展
    4.9 どの手法をいつ使うか? 
    4.10 リモートでの協働モデリング
    4.11 協働モデリングとAI 
    4.12 その他の協働モデリング手法
    4.13 まとめ

5章 ソフトウェアアーキテクチャの概念
    5.1 C4モデルによるアーキテクチャドキュメント
        5.1.1 レベル1:コンテキスト
        5.1.2 レベル2:コンテナ
        5.1.3 レベル3:コンポーネント
        5.1.4 レベル4:コード
    5.2 モジュール性
    5.3 凝集度と結合度
        5.3.1 DDDにおける凝集度と結合度
        5.3.2 ドメインにおける凝集度と結合度
    5.4 大きな泥団子
        5.4.1 クラスレベルにおいて
        5.4.2 アーキテクチャレベルにおいて
        5.4.3 大きな泥団子はどこからくるのか? 
        5.4.4 結合度と再利用
    5.5 レガシーシステムのためのアーキテクチャスタイル
    5.6 モノリス
    5.7 マイクロサービス
    5.8 モノリスからマイクロサービスへ
    5.9 定番のレイヤードアーキテクチャ
    5.10 インサイドアウトアーキテクチャ:ヘキサゴナル/ポートとアダプタ、オニオン、クリーン他
        5.10.1 さまざまなスタイルの統合:エクスプリシットアーキテクチャ
        5.10.2 インサイドアウトアーキテクチャと戦術的DDD 
    5.11 ソフトウェアアーキテクチャハンバーガー
    5.12 サービス指向アーキテクチャ
    5.13 自己完結型システム
    5.14 IT ランドスケープからSOAへ、そして再び
    5.15 モジュール性成熟度インデックス:あなたはどの位置にいるか? 
        5.15.1 MMIにおけるモジュール性
        5.15.2 MMIにおける階層
        5.15.3 MMIにおけるパターン一貫性
    5.16 MMIの計算
    5.17 まとめ

6章 トランスフォーメーションへのアプローチ方法
    6.1 置き換え:ビッグバン
    6.2 置き換え:ステップバイステップ
    6.3 リシェイピング
    6.4 まとめ

第II部 技術的・戦術的・チーム組織的なドメイン駆動トランスフォーメーション
    II.1 あなたの現状は?(簡易版) 

7章 レガシーシステムの技術的安定化
    7.1 統合開発環境のアップデート
    7.2 ビルドとデプロイメントの自動化
    7.3 ソフトウェア依存関係のアップデート
        7.3.1 ライブラリとフレームワークのアップデート
        7.3.2 プログラミング言語のアップデート
        7.3.3 コンパイラとIDEの警告の解消
    7.4 バグ修正時のテストカバレッジ向上
        7.4.1 スカウトルール
        7.4.2 さまざまな種類のテスト
    7.5 作業の中でのコードのクリーンアップ
    7.6 リファクタリング
        7.6.1 依存関係の解消
        7.6.2 メトリクスを用いた内部構造の改善
    7.7 エラー堅牢性の向上
        7.7.1 null に対する堅牢性の構築
        7.7.2 例外の使用の改善
        7.7.3 契約による設計の導入
    7.8 まとめ
    7.9 あなたの現状は?(簡易版) 

8章 ドメイン知識によるソースコードの強化
    8.1 ビジネスソースコードと技術ソースコードの分離
    8.2 凝集の向上
        8.2.1 モデリングのドメイン知識による強化
        8.2.2 値オブジェクトの活用
        8.2.3 契約による設計の導入
        8.2.4 エンティティの識別子の明示化
    8.3 結合の削減
        8.3.1 循環依存と依存関係の解消
        8.3.2 アグリゲート境界でのID 参照の導入
        8.3.3 ビジネスソースコードにおける継承の削減
        8.3.4 Liskov の置換原則
    8.4 コード内でのアーキテクチャの文書化
    8.5 AI は私のドメインについて知識を持っているか? 
    8.6 まとめ
    8.7 あなたの現状は?(簡易版) 

9章 チーム組織の改善
    9.1 社会技術的システムとしてのソフトウェア
        9.1.1 水平なアーキテクチャ・チーム組織
        9.1.2 垂直なアーキテクチャ/チーム組織
        9.1.3 チームの再組織化の進め方
    9.2 チームトポロジー
        9.2.1 フロー状態での作業
        9.2.2 トポロジーの種類
        9.2.3 チームインタラクションモード
        9.2.4 時間経過とともに進化するチーム
        9.2.5 アーキテクチャモダナイゼーションイネーブリングチーム
    9.3 まとめ
    9.4 あなたの現状は?(簡易版) 

第III部 戦略的ドメイン駆動トランスフォーメーション
    III.1 ブラウンフィールドでのソフトウェア開発
    III.2 鍵はドメインの(再)発見・(再)理解
    III.3 戦略的トランスフォーメーションの概要
    III.4 この部の構成

10章 ステップ1 ―ドメイン再発見
    10.1 ステップ1 の概略
    10.2 課題:適切なドメインエキスパートの招集
    10.3 課題:ドメインエキスパートを実際のドメインへ戻す
    10.4 サブステップ1.1:as-is 状況の把握
    10.5 サブステップ1.2:ドメイン知識の抽出(純化)
        10.5.1 テクニック:思考実験「ペーパープロセス」
        10.5.2 テクニック:思考実験「バーチャルアクター」
        10.5.3 別のアプローチ:最初から純粋にモデリングする
        10.5.4 ユビキタス言語の蒸留
    10.6 サブステップ1.3:ビジネスプロセスの最適化
    10.7 サブステップ1.4:ビジネスプロセスにおけるサブドメインの特定
        10.7.1 サブドメインの境界を示す指標
    10.8 課題:作業項目では分解しない
    10.9 課題:適切な規模の見極め
        10.9.1 適切な規模の目標
        10.9.2 適切な規模の指標
    10.10 AI との分解の議論
    10.11 まとめ

11章 ステップ2 ―ドメイン駆動ターゲットアーキテクチャのモデリング
    11.1 ステップ2 の概略
    11.2 サブステップ2.1:コンテキストマップの作成
    11.3 課題:解決空間に由来するコンテキスト
    11.4 サブステップ2.2:サブドメインの分類
    11.5 サブステップ2.3:境界づけられたコンテキストのチームへの割り当て
    11.6 課題:チームの割り当ては多くの場合チームの再編成を意味する
    11.7 サブステップ2.4:関係の決定
    11.8 全体の整理
    11.9 まとめ

12章 ステップ3 ―現状のアーキテクチャとターゲットアーキテクチャのすり合わせ
    12.1 ステップ3 の概略
    12.2 サブステップ3.1:現状のアーキテクチャの特定
        12.2.1 現状のアーキテクチャとAI 
    12.3 サブステップ3.2:ターゲットコンテキストマップとソースコードの比較
    12.4 課題:無境界モデル
        12.4.1 内から外への分解
    12.5 課題:無境界ドメインモデル
        12.5.1 問題の原因:再利用性の誤解
    12.6 課題:無境界貧血ドメインモデル
    12.7 課題:無境界データモデル
    12.8 課題:ユーザインターフェースの分解
        12.8.1 モノリシックUI 
        12.8.2 コンテキスト内のUI:マイクロフロントエンド
    12.9 サブステップ3.3:リファクタリング項目と発見事項の整理
    12.10 まとめ

13章 ステップ4 ―トランスフォーメーション施策の優先順位づけと実施
    13.1 ステップ4 の概略
    13.2 サブステップ4.1:最初の戦略的リファクタリングの選択
        13.2.1 指針:支援サブドメインから始める
        13.2.2 指針:コアドメインへと進む
    13.3 サブステップ4.2:戦術的リファクタリングのプロダクトバックログ(または改善バックログ)への追加
    13.4 サブステップ4.3:スプリントバックログに入れるリファクタリングの計画
        13.4.1 緊急時のみリファクタリングを一時停止する
        13.4.2 リファクタリングの見積もり
        13.4.3 カンバンによるドメイン駆動トランスフォーメーション
    13.5 サブステップ4.4:コンテキストの抽出
    13.6 課題:サービスにおけるビジネスロジックの分離
    13.7 課題:ローカルデータ、setter、getter のコンテキストへの移動
        13.7.1 エンティティの識別子
    13.8 課題:データ、setter、getter の複数コンテキストへの複製
    13.9 課題:サービス間へのドメインイベントの導入
    13.10 課題:ドメインロジックをサービスから貧血ドメインモデルに移す
        13.10.1 サービスから貧血エンティティへのロジックの押し込み
    13.11 課題:データモデルの分離
    13.12 課題:発見事項を適切なタイミングで選択する
    13.13 課題:スタミナの維持
    13.14 まとめ

第IV部 総括

14章 今後に向けて:ドメインパターンと境界づけられたコンテキストへの実装
    14.1 観点1:ドメイン内のワークフロー
        14.1.1 ドメインパターン「パイプライン」
        14.1.2 ドメインパターン「ブラックボード」
        14.1.3 ドメインパターン「ダイアログ」
        14.1.4 ドメインの進化とパターン
    14.2 観点2:ソフトウェアにおけるドメインモデル
        14.2.1 中心的なドメインアイテムと多様なドメインアイテム
        14.2.2 フォームベースのドメインモデル
    14.3 観点3:ドメインの形状
        14.3.1 ドメインの歴史と成熟度
        14.3.2 有形オブジェクトドメインと完全デジタル化ドメイン
        14.3.3 トランスフォーメーションの余地
    14.4 まとめ

15章 ドメイン駆動トランスフォーメーションのまとめ

付録A ドメイン駆動リファクタリングカタログの概要

付録B 戦略的リファクタリング
    B.1 コンテキストの抽出
    B.2 境界づけられたコンテキストをゼロから実装

付録C 戦略的リファクタリングを支える戦術的リファクタリング
    C.1 特化サービスの抽出
    C.2 特化エンティティの抽出
    C.3 特化貧血エンティティの抽出
    C.4 特化テーブルの抽出

付録D 社会技術的リファクタリング
    D.1 レイヤーチームメンバーによるクロスファンクショナルチームの編成
    D.2 レイヤーチームと第1 チームのメンバーによる第2 クロスファンクショナルチームの編成
    D.3 レイヤーチームメンバーのみによる第2 チームの編成

付録E ドメイン知識を強化する戦術的リファクタリング
    E.1 ユビキタス言語の徹底
    E.2 プリミティブ型の値オブジェクトへの置き換え
    E.3 貧血エンティティの改善
    E.4 setter の置き換え
    E.5 setter の除去
    E.6 サービスからエンティティへのロジック移動
    E.7 コントラクトの導入
    E.8 アクティブレコードをアグリゲートとリポジトリに分割
    E.9 リポジトリをインターフェースと実装に分割
    E.10 スマートUI からエンティティを抽出
    E.11 スマートUI からサービスを抽出

参考文献
索引