分散型アーキテクチャとドメイン駆動設計

JJUG ナイトセミナー　2025/1 発表資料」

Transcript

1. 分散型アーキテクチャと ドメイン駆動設計 2025年1月27日 有限会社システム設計 増田 亨 1 JJUGナイトセミナー「新春Java2025」
2. 自己紹介 業務系アプリケーションソフトウェアの開発者 モデル駆動設計 Java/Spring Boot/IntelliJ IDEA/JIG 有限会社システム設計 代表 since 2003 コミューン株式会社 技術アドバイザ since 2023 2 増田 亨（ますだ とおる） 著書(2017) 訳書(2024)
3. 本日お話する内容 1. 分散型アーキテクチャの時代 • 溢れかえるデータ • 多種多様なアプリケーション 2. ドメイン駆動設計のアプローチ • どう分けるか • どうつなぐか • どう整えるか 3
4. 分散型アーキテクチャの時代 4
5. 溢れかえるデータ いつでも、どこでもデータが発生 • スマートフォン、タブレット、ウェアラブル、ＰＣ • 位置センサー、運動センサー、音声認識、画像認識 飛び回るデータ • wifi、光ファイバー、衛星通信 低コスト大容量のデータストレージ • クラウドストレージ(ファイル、オブジェクト） • マネージドデータベース（RDBMS、NoSQL、NewSQL） 5
6. 多種多様なアプリケーション • 基幹システム、Webアプリ、モバイルアプリ、… • Salseforce、SAP、… • 勘定奉行クラウド、freee会計、楽々明細、SmartHR、… • kintone、… • Stripe、SBペイメントサービス、… • Asteria Warp、DataSpider、… • Tableau、RedShift、BigQuery、 Snowflake、… 6
7. 成長を続ける分散した大きな泥団子 溢れかえるデータ×多種多様なアプリケーション 増殖するデータ、増殖するアプリケーション 増殖するデータ連係、増殖するAPI連携 誰も全体を知らない 誰も全体をコントロールできない 全体としてどこに向かっているのか誰もわからない それでも成長を続ける分散した大きな泥団子… 7
8. 対処方法？ • エンタープライズアーキテクチャ？ • グランドデザイン？ • マスタープラン？ • エンタープライズサービスバス？ • 全社統一データモデル？ 8 集中統一アプローチの終焉
9. 分散型アーキテクチャの設計課題 どう分けるか どうつなぐか どう全体を整えるか 9
10. 一筋の光明 10
11. 分散型アーキテクチャ時代のドメイン駆動設計 11 (2024年) (2021年) (2015年) (2013年) (2011年) (2003年)
12. 分散型アーキテクチャ ドメイン駆動設計のアプローチ 12
13. ドメイン駆動設計の考え方 ① 事業活動をうまく表現するようにソフトウェアを構造化する ② 事業を構成する業務活動を業務ごとの個別モデルで表現する ③ 競争戦略の実現手段としてソフトウェアシステムを整える 13
14. どう分けるか？ 14
15. 「はじめに」 この本で学んでほしいことは、 ソフトウェア設計と事業方針を密接に関係づける ことの効果です。 15 事業方針の中心課題は競争優位性 そことソフトウェア設計を整合させる
16. 事業活動とソフトウェアの基本構造 16 購買 物流 変換 組立 出荷 物流 販売促進 販売 アフター サービス 外部調達 技術開発 人的資源管理 基盤活動（財務、会計、法務、…） ５つの 主活動 ４つの 支援活動 ポーター 競争優位の戦略 価値連鎖モデル ＝分散型アーキテクチャの参照モデル 数百の事業事例を 調査分析し一般化
17. 競争優位性の観点から業務活動を三分類 中核の業務領域 • 競争優位の源泉 • 競合他社が簡単にまねができない独自のやり方 • 業務ロジックは必然的に複雑になる • 進化し続ける（競争優位を維持し続ける）ことが必要 一般的な業務領域 • 他社と同じやり方でよい • 業務ロジックは複雑だが進化させる必要ない • この領域を独自に開発すべきではない 補完的な業務領域 • 自社独自のやり方が必要 • 業務ロジックは単純（CRUDやETL） 17 事業活動を「業務領域」に細分化 三つのカテゴリーへの分類が 設計判断の基本枠組みとなる
18. 業務領域のカテゴリー 分類方法 18 競合他社との差別化 中核に重点的に取り組む（事業価値が最も高い） 一般はパッケージやクラウドサービスを検討 補完はできるだけ手間をかけずにすませる 中核 業務ロジックの複雑さ 二軸で分類
19. 業務領域のカテゴリーの比較 中核 一般 補完 競争優位 ◎ × × 複雑さ 〇 〇 × 変化 〇 × × 実装 内製 購入 外注 19
20. 業務領域のカテゴリーとモデリング • 中核（競争優位の源泉） ⇒ 状態更新型のドメインモデリング ⇒ イベント中心型のドメインモデリング • 一般（他社と同じ、ロジックは複雑） 既存モデルを流用（独自にモデリングしない） • 補完（自社独自、ロジックは単純、CRUD/ETL） ⇒フラットなレコード型のデータモデリング（トランザクションスクリプト） ⇒ データ構造が入り組んだデータモデリング（アクティブレコード） 20
21. ドメイン駆動設計：分割の根底技法 カプセル化の境界を設計する • 境界の内側に関連するデータとロジックを凝集する • 関係しないデータとロジックは境界の外側に分離する • 境界を越える相互作用を厳密に定義する（契約による設計） 関連キーワード • 関心の分離 • モジュール化 • データ抽象 • 型 • インターフェース定義 21
22. ドメイン駆動設計：カプセル化の階層 値オブジェクト • 業務ルールを表現する基本部品 • 金額、数量、日付に関わる計算判断ロジックをカプセル化 集約（値オブジェクトの集合） • 値付け、割引、与信、オーバーブッキング、引当など個別ビジネスルールをカプセル化 パッケージ（名前空間、値オブジェクトと集約の集合） • 活動ポリシー（ビジネスルールの集合）をカプセル化 アプリケーション（区切られた文脈） • 業務活動（業務アクション、業務ロジック、業務データ）をカプセル化 • 個別モデルの通用範囲の境界 22 JVMがこの気持ちを分かってくれるその日まで… アプリケーション ごとのデータストア
23. ドメイン駆動設計のアーキテクチャ原則 アダプターの分離 • アプリケーション本体と、アダプター（プレゼンテーション層、デー タソース層、通信層）を分離する • いわゆるポート＆アダプター方式 ビジネスルール独立 • ビジネスプロセスや業務フローの記述（業務アクションの記述）と、 ビジネスルールの記述を分離する • いわゆるドメインモデル方式 23
24. どうつなぐか？ 24
25. つなぎ方：ドメイン駆動設計の考え方 アプリケーションごとに個別のドメインモデルがある アプリケーション間の連係はモデルの変換である • アダプター間の通信仕様ではない RESTクライアント、RESTコントローラ、OpenAPI • それぞれのドメインモデルの主要な構成要素（値オブジェクト と集約）の、どの要素をどういう方針で変換するかを設計する アダプター、ラッパー、コンバーター、トランスフォーマー、ファサード、プロキ シー、ゲートウェイ、コンテントフィルター、エンリッチャー、… 25
26. 区切られた文脈（異なるモデルの境界） 26 • 同じ言葉の通用する範囲 • 開発単位の境界 • チームの責任範囲の境界 内側に集めるロジックとデータ 外側に分離するロジックとデータ 複雑さを扱うために 文脈を区切る （第３章） 顧客 商品 顧客 商品 顧客 商品
27. つなぎ方（モデルの変換）の選択肢 27 対等の関係 力関係が片寄った関係 顧客共通 顧客 顧客 顧客 顧客 顧客 顧客 顧客 顧客
28. 異なるモデル間の連係マップ 28 この地図からわかること ・顧客管理が中核の業務領域 ・それ以外は一般または補完 中核モデルの独自性を保護する
29. 分散型アーキテクチャのドメインモデリング 29 マイクロサービスアーキテクチャ （第14章） イベント駆動型アーキテクチャ （第15章） データメッシュ （第1６章） 区切られた文脈の考え方で取り組む
30. どう全体を整えるか？ 30
31. ドメイン駆動設計のアプローチ 事業戦略の実現手段としてソフトウェアシステムを整える しかし… • 現実のさまざまな業務活動は戦略的に整合しているのか？ • おそらく、多くの企業は、それほど明確な事業戦略を持っていない し、全体を事業戦略に整合できてはいない とはいえ… • それなりに利益を確保し、事業を存続できていることも事実 31
32. 事業活動は全体として機能している • 事業活動も、ある意味で、分散した大きな泥団子ではある • しかし、何か大きな状況の変化や、部門をまたがって解決すべき課 題が発生すると、関係部署をまたがった調整活動が行われる • 部門間をまたがった臨時の調整会議など • ソフトウェアシステムのアプリケーション間連係の調整も、この事 業活動の調整機能と連動する必要がある • アプリケーションをまたがる調整活動を事業活動、事業戦略を理解 したソフトウェアエンジニアが主体的に行う 32
33. 全体を整えるソフトウェアエンジニア • 技術的な知識と技能だけでは不十分 • ソフトウェアアーキテクチャの見方に事業視点を追加する • 事業活動全体をとらえるフレームワークを活用する • 担当部分の境界の設計判断に、事業活動の構造知識を活用する おすすめ：マイケルポーター競争優位の戦略 • 数百の事業活動の分析結果から生まれた一般モデル • うまくいく事業と、そうではない事業の差がなぜ生まれるかの分析 • あらゆる事業活動のデジタル化が進む現代では、事業活動の分析モデルが、そのま まソフトウェアシステムの分析モデルとして有用 33
34. 分散型アーキテクチャの時代 参考書籍 34
35. 事業視点で設計判断するための推薦図書 35