中核の業務領域 2024年8月29日 有限会社システム設計 増田 亨 1 BPStudy #204 ～ドメイン駆動設計をはじめよう 『ドメイン駆動設計をはじめよう』

自己紹介 業務系アプリケーションソフトウェアの開発者 モデル駆動設計 Java/Spring Boot/IntelliJ IDEA/JIG 有限会社システム設計 代表 since 2003 コミューン株式会社 技術アドバイザ since 2023 2 増田 亨（ますだ とおる） 著書(2017) 訳書(2024)

『ドメイン駆動設計をはじめよう』 Amazon.comで高評価(★4.6, 302review) “Learning Domain-Driven Design” の全訳 「ドメイン駆動設計を実践するために 最初に手にするべき1冊！」 by 出版社 ドメイン駆動設計抜きにしても、よいことが書いてある by もう一人の訳者綿引さん 3 ソフトウェアの実装と事業戦略を結びつける実践技法

この本を特徴づける三つのキーワード ①中核の業務領域 ②区切られた文脈 ③分散型アーキテクチャ 4 今日の発表の中心 （モデルと言葉の一貫性） （通信方式、マイクロサービス、イベント駆動、データメッシュ）

中核の業務領域 5 Core Subdomain

中核の業務領域 事業活動の中で競争優位を生み出す活動 事業活動を中核、補完、一般に三分類する • エヴァンス本にはでてこない考え方 • ヴァーノン本で提示された考え方をさらに発展させた感じ この三分類から設計方針を決める 6

「はじめに」xxixより “この本で学んでほしいことは、 ソフトウェア設計と事業方針を 密接に関係づけることの効果です。” 7 事業方針の核心が競争優位、そことソフトウェア設計を整合させる

設計 判断 本書の構成：事業方針とソフトウェア設計 8 事業活動 課題 課題 仕組み 仕組み 関係者 開発者が理解 トランザクション スクリプト アクティブ レコード ドメイン モデル イベント履歴式 ドメインモデル 値オブジェクト 集約 業務サービス レイヤード ポートと アダプター CQRS Web API メッセージング 送信箱 サーガ プロセス マネージャー イベント駆動型 アーキテクチャ マイクロ サービス データメッシュ トランザクション ロールバック 排他制御 テスト戦略 イベント ストーミング 大きな リファクタリング （第１章～第４章） 設計の選択肢（第５章～第１６章） （第10章、付録A） 実践知 競争優位

ソフトウェア設計と事業方針 この本の考え方 1. ソフトウェアを開発する目的は事業を成長させること 2. 事業を成長させるためには、ソフトウェアの修正と拡張が必要 3. 設計と事業方針が結びつけば、変更が楽で安全になる 9 こういう視点で、ソフトウェア設計の考え方とやり方を説明している本 技術的な実装方法だけを学びたいなら、適切な本ではない

ソフトウェアの実装と 事業戦略を結びつける方法 10

基本的なやり方 11 事業活動全体を複数の業務領域に分解 それぞれの業務領域を事業戦略の視点から 三つのカテゴリーに分類 業務領域のカテゴリーが決まれば 業務ロジックの実装方法が決まる 業務ロジックの実装方法が決まれば アプリケーションの技術方式が決まる 業務ロジックの実装方法が決まれば テスト方針が決まる 第１ステップ 第２ステップ 第３ステップ 第４ステップ 第５ステップ ここがキモ！

事業活動を業務領域に分解する 事業活動（ドメイン） • 顧客にどんな価値を提供しているか • どうやってその価値を提供しているか • 競合他社とどうやって差別化し競争優位を生み出し維持するか 業務領域（サブドメイン） • 事業活動の領域全体を細分化したもの • すべての業務領域が一体となって顧客に価値を提供する • 販売促進、販売、顧客サービス、出荷、在庫、会計、財務、人事、… 12

業務領域のカテゴリーを特定する 13 二軸で分類 ・競合他社との差別化 ・業務ロジックの複雑さ 中核に重点的に取り組む（事業価値が最も高い） 一般はパッケージやクラウドサービスを検討 補完はできるだけ手間をかけずにすませる 中核

事業戦略の視点から業務領域を分類 中核の業務領域 • 競争優位の源泉 • 競合他社が簡単にまねができない独自のやり方 • 業務ロジックは必然的に複雑になる • 進化し続ける（競争優位を維持し続ける）ことが必要 一般的な業務領域 • 他社と同じやり方でよい • 業務ロジックは複雑だが進化させる必要ない • この領域を独自に開発すべきではない 補完的な業務領域 • 自社独自のやり方が必要 • 業務ロジックは単純（CRUDやETL） 14 業務領域の細分化と 三つのカテゴリーへの分類が 設計判断の基本枠組みとなる

三つのカテゴリーの比較 中核 一般 補完 競争優位 〇 × × 複雑さ 〇 〇 × 変化 〇 × × 実装 内製 購入 外注 15

業務ロジックの実装方法の選択 16 （第５章） （第６章） （第７章） （第１章） 中核の 業務領域

業務領域のカテゴリーから 業務ロジックの実装方法が決まると 17 アプリケーションの技術方式が決まる テストの基本方針が決まる （第８章） （第１０章）

業務領域の分類の具体例（第１章） 18 中核（競争優位） • 推薦エンジン • データの匿名化 • モバイルアプリ 一般 • 暗号化 • 会計 • 決済 • 認証と認可 補完 • 音楽ストリーミングサービスとの連係 • SNSとの連携 • ライブ参加履歴の管理 中核（競争優位） • 運行経路の選択 • 利用者の行動分析 • モバイルアプリ • 車両の管理 一般 • 交通状況 • 会計 • 請求 • 認証と認可 補完 • クーポン発行 • クーポンの有効性チェック ライブチケットのオンライン販売事業 相乗りタクシー型ミニバスサービス こういう事業分析や業務知識の具体例が多いのがこの本の価値

事業の成長と ソフトウェアの成長 19 （第11章 設計を進化させる）

業務領域のカテゴリーは変化する 20 事業が成長すれば、業務領域の カテゴリーは変化する 業務領域のカテゴリーの変化に応じて 設計方針を変える

業務領域のカテゴリーに合わせた設計 21 （第１章） （第５章） （第６章） （第７章） 中核の 業務領域

区切られた文脈 22 Bounded Context ＜時間があれば＞

区切られた文脈 • ３章 事業活動の複雑さに立ち向かう • 言葉が同じ意味で通用する範囲 • モデルの一貫性を維持するための境界 • 一つのチームが責任をもって取り組む範囲 23

第一の学び：「同じ言葉」の効果 24 業務知識が欠落するソフトウェア開発 業務知識が豊富なソフトウェア開発 同じ言葉 （業務の言葉） （第２章）

第二の学び：「区切られた文脈」の効果 25 • 同じ言葉の通用する範囲 • モデルの境界 • 開発単位の境界 • チームの責任範囲の境界 複雑さを扱うために 文脈を区切る （第３章）

分散型アーキテクチャと ドメイン駆動設計 26 ＜時間があれば＞ こういう内容も書かれています（４章、９章、14章、15章、16章）

第４章 区切られた文脈どうしの連係 27 対等の関係 力関係が片寄った関係

文脈の地図（連係の全体像） 28 この地図からわかること ・顧客管理が中核の業務領域 ・それ以外は一般または補完 中核モデルの独自性を 保護するための設計判断

第９章 通信 29 （区切られた文脈どうしの連係を実装する技術方式）

ドメイン駆動設計と分散型アーキテクチャ 30 マイクロサービスアーキテクチャ （第14章） イベント駆動型アーキテクチャ （第15章） データメッシュ （第1６章） 区切られた文脈の考え方で取り組む