ドメイン駆動設計のための Spring の上手な使い方

ドメイン駆動設計のための Spring の上手な使い方

1. 1. ドメイン駆動設計のための Springの上手な使い方 2017年11月24日 ギルドワークス 増田 Spring Fest 2017 1
2. 2. 自己紹介 コード ：https://github.com/system-sekkei/isolating-the-domain ブログ：システム設計日記 http://masuda220.jugem.jp/ https://www.slideshare.net/masuda220/ コードを書くのが楽しくて、作ったソフトウェアを使ってもらえとうれしい、どこにでもいる技術者 2
3. 3. お話しする内容 ドメイン駆動設計とは何か Spring のプログラミングモデル ドメイン駆動設計のための Springの使い方 3
4. 4. ドメイン駆動設計とは何か What is Domain-Driven Design 4
5. 5. 価値のあるシステムを構築する方法 成長し価値を加え続けるソフトウェア 厳しい現実の中での設計の実践技法 ドメイン駆動設計 5
6. 6. 開発者がドメインを学ぶ モデルと実装を一致させる 深いモデルを探求する ドメイン駆動設計の基本活動 巨大な複雑さに立ち向かう 6
7. 7. 開発者がドメインを学ぶ モデルと実装を一致させる 深いモデルを探求する ドメイン駆動設計の基本活動 巨大な複雑さに立ち向かう 7
8. 8. 開発者がドメインを学ぶ 対象領域（ドメイン）の知識を広げる 学んだことをコードで表現する 8
9. 9. 対象領域（ドメイン）の知識を広げる • 業務の用語／言い回しを覚える • 登場人物、活動の目的、関心事、… • 活動の内容、タイミング • ルール、前提、制約、… • 表面的な言葉の理解から始める • しだいに深い洞察へ • 背景にある構造や原理を言語化する • 継続的に学習する 9
10. 10. 学んだことをコードで表現する • ドメインの知識をコードで表現する基本スキル • 値オブジェクト、コレクションオブジェクト、区分オブジェクト • 識別オブジェクト、集約 • Repository, Factory • 知識の増加がコードに現れる • パッケージ名、クラス名、インタフェース名、メソッド名 • 洞察の深さがコードに現れる • パッケージの構造、オブジェクトの参照関係、… • コードレビュー：ドメインの学習成果のレビュー • パッケージ名、クラス名、インタフェース名、メソッド名、… • 参照関係／グルーピングの範囲 • コードで表現されたドメインの知識の量は？ 質は？ • コードでの知識表現に工夫の余地は？ 10 技術者はエクセルで知識を表現してはいけない
11. 11. 開発者がドメインを学ぶ モデルと実装を一致させる 深いモデルを探求する ドメイン駆動設計の基本活動 巨大な複雑さに立ち向かう 11
12. 12. モデル • 選び抜かれた重要な 側面 • 蒸留された本質的な知 識 • 全体を形づくる主要な 骨組み 12
13. 13. モデル • 選び抜かれた重要な 側面 • 蒸留された本質的な知 識 • 全体を形づくる主要な 骨組み 実装 • 大量かつ網羅的な記 述が必要 • 重要ではないが、省略 はできない細部の記述 • 肥大化したコード、重 複したコードとの戦い 13
14. 14. モデル • 選び抜かれた重要な 側面 • 蒸留された本質的な知 識 • 全体を形づくる主要な 骨組み 実装 • 大量かつ網羅的な記 述が必要 • 重要ではないが、省略 はできない細部の記述 • 肥大化したコード、重 複したコードとの戦い モデルと実装を関連づけることで、実装が整理され、見通しが良くなる 実装からフィードバックすることで、モデルが実用的になる 14
15. 15. モデルと実装を一致させる • ドメインの記述を、技術の関心事から独立させる • isolating-the-domain • Spring のプログラミングモデル • 概念の単位とプログラミングの単位を一致させる • オブジェクト指向によるモジュール化 • 型（クラス、インタフェース、enum）で、知識を表現する • 基本データ型ではなく、ユーザ定義型で表現する • 最初からぴったりの型は見つからない • 実験→フィードバック→設計の改善を繰り返す 15
16. 16. 開発者がドメインを学ぶ モデルと実装を一致させる 深いモデルを探求する ドメイン駆動設計の基本活動 巨大な複雑さに立ち向かう 16
17. 17. 深いモデルを探求する • 中核の複雑さ／機会に焦点を合わせる • 中核を探す活動 • 仮説と検証 • 役に立つ型を見つけるための実験を繰り返す • 暗黙の概念を明示的に表現する • 暗黙になりがちな知識を明示的に表現する工夫 • しなやかな設計 • 複雑になっても成長を続けることができる設計 • 重複を徹底的に取り除く（オブジェクト指向設計） 17
18. 18. 暗黙になりがちな知識を 明示的に表現する工夫 • 制約 • Bean Validationで、正しい値を明示的に表現する • Policy { Set<Predicate<T>> rules } • プロセス（業務の流れ／手順） • 流れの構造の表現 ： Set<Action>, Action#nextAction() • 行動の記録 ： List<Event> • 区分の分析 • enumによる区分名の列挙（コードから日本語名へ） • enumのリファクタリング • MECE : Mutually Exclusive and Collectively Exhaustive 相互に排他的、かつ、網羅的 • そうなっていない区分の背景を深掘る • enumに振る舞い（判断／加工／計算）を持たせる 暗黙の知識を宣言的に表現できると、if文がどんどん減っていく18
19. 19. 開発者がドメインを学ぶ モデルと実装を一致させる 深いモデルを探求する ドメイン駆動設計の基本活動 巨大な複雑さに立ち向かう 19
20. 20. 巨大な複雑さに立ち向かう • 戦略的に取り組む • 時間がかかる • 地道な努力の積み重ねのエネルギー • モデルを探求する • このレベルでも、モデルとコードを一致させる • コードに責任を持つ開発者がリードする • 巨大な複雑さに立ち向かうためのスキル • 俯瞰 • 蒸留 • 大きな構造化 20
21. 21. 開発者がドメインを学ぶ モデルと実装を一致させる 深いモデルを探求する ドメイン駆動設計の基本活動 巨大な複雑さに立ち向かう 21
22. 22. Spring のプログラミングモデル Spring Programming Model 22
23. 23. Spring のプログラミングモデル also known as ドメインオブジェクト アノテーション Java-based configration application.properties 23
24. 24. Spring のプログラミングモデル also known as ドメインオブジェクト アノテーション Java-based configration application.properties ドメイン駆動設計の 活動の中心 24
25. 25. Spring のプログラミングモデル also known as ドメインオブジェクト アノテーション Java-based configration application.properties ドメイン駆動設計の 活動の中心 ドメイン駆動設計を実践した場合 何が変わるのか／変わらないのか 25
26. 26. Springのプログラミングモデル Springはアプリケーションの「基盤」を提供する 開発者は、ドメイン固有のロジックに集中する ドメイン駆動設計の考え方そのもの focus on your specific domain model implement with plain Objects 26
27. 27. Springのプログラミングモデル Springはアプリケーションの「基盤」を提供する 開発者は、ドメイン固有のロジックに集中する ドメイン駆動設計の考え方そのもの focus on your specific domain model implement with plain Objects DDD本が出版された後、Springドキュメントに、DDDを意識した記述が増えた @Service, @Repositoryは、DDD本に由来する エヴァンスは、EJBからSpringへのシフトは大きな転換だったと振り返っている Springは ドメイン駆動設計を実践するためのフレームワーク 27
28. 28. Spring ドメインとドメインロジックに集中できる ドメインの分析と理解に時間を割ける ドメインロジックのコードがフレーム ワークに汚染されない 28
29. 29. Spring こんな使い方もあります… 29
30. 30. ドメインとドメインロジックに集中 技術課題に集中する モデルに基づき設計する バックログをせっせと消化する 分析・設計・実装を単一の活動に フェーズに分けて伝言ゲーム 基盤チームとアプリチームの分離 30
31. 31. プレゼンテーション層 データソース層 アプリケーション層 画面の入出力 データベースの入出力 データベースの 更新・参照の手続き データの加工ロジック データの検証ロジック データの判断／加工／計算 書き込みの前処理ロジック 読み出しの後処理ロジック データ処理に焦点をあてる @Controller @Service @Repository 31
32. 32. トランザクションスクリプト ドメインロジックが重複しない 同じロジックが重複する どこにロジックが書いてあるか 特定しやすい データ処理の流れを追いかけて探しまわる 変更の影響を狭い範囲に限定できる 後続の処理をすべて追いかける 32
33. 33. Spring ドメイン駆動設計らしい使い方 33
34. 34. ドメインとドメインロジックに集中 モデルに基づき設計する 分析・設計・実装を単一の活動に 核心の複雑さに立ち向かう 34
35. 35. プレゼンテーション層 データソース層 アプリケーション層 ドメインを独立させる @Controller @Service @Repository ドメインモデル ここを インクリメンタルに 成長させながら 全体の開発を駆動する ドメインロジックを ここに集約する 35
36. 36. ドメインモデル ドメインロジックが重複しない どこにロジックが書いてあるか 特定しやすい 変更の影響を狭い範囲に限定できる データを持つクラスが唯一のロジックを持つ パッケージ名→クラス名 変更したクラスに閉じる パッケージに閉じる そのクラスを直接使うクラスまでに閉じる 36
37. 37. ドメイン駆動設計のための Spring の使い方 Spring Integration Spring Batch Spring Security 37
38. 38. 38
39. 39. 初日から、動くアプリケーションで考える 初日から、学んだことをコードで記録する 初日から、コードでモデルを表現してみる 初日から、End to End で実験してみる gitですべての履歴を管理 spring-boot-starter-* 動く画面でフィードバック、実データからのフィードバック ドメインを学ぶ モデルと実装の一致 深いモデルの探求 巨大な複雑さに立ち向かう 39
40. 40. Spring Integration 40
41. 41. Spring Integration ドメインを学ぶ モデルと実装の一致 深いモデルの探求 巨大な複雑さに立ち向かう • 複数のアプリケーションの連携という課題 • 境界づけられたコンテキスト（Bounded Context） • コンテキストマップ（Context Map） • モデルとモデルの連携パターン • EIP(Enterprise Integration Patterns)の実装技術 • メッセージングモデル • 分散／非同期／並列 • イベントソーシング • 結果整合性 githubリポジトリ 41
42. 42. Enterprise Integration Patterns 巨大な複雑さを分析・設計・実装するための 枠組みと共通の語彙 42
43. 43. Spring Integration • データ通信の技術 vs. 業務モデル • メッセージングモデルは、業務のモデルでもある • ドメインの知識がコードに現れる場所 • message名/channel名/endpoint名 • コンポーネントの粒度、名前づけ、組み合わせ方 • Transformer • Filter • Router • Splitter/Aggregator • Scatter/Gather • Service Activator • Channel Adapter • 開発者のドメインへの意識/理解の違いが、設計（コー ド）にそのままでてくる 43
44. 44. Spring Batch 44
45. 45. Spring Batch アーキテクチャ Step フロー定義45
46. 46. Spring Batch • バッチ処理：今でも、多くの業務を裏で支えている • 大量のデータ処理技術 vs. 業務モデル • Job/Taskモデルは、業務のモデルでもある • ドメインの理解度の違いが表れる場所 • Job / Step / Step Flow • Job Launcher/ Schedule 定義 • Completion policy • Retry Policy • Exception Handling • RepeatListener (before/after/open/close/onError) • 構成メタデータで、ドメインの知識を表現する ドメインを学ぶ モデルと実装の一致 深いモデルの探求 巨大な複雑さに立ち向かう 46
47. 47. 47
48. 48. Spring Security • 認可モデル ： 業務の重要な関心事 • できる／できない • 見える／見えない • 認可モデルを宣言的に明示する手段 • Role／権限 • Roleの分析と定義 • 権限の分析と定義 • UserとRoleの関係 • Roleと権限のひもづけ • RoleとRoleの構造化 ドメインを学ぶ モデルと実装の一致 深いモデルの探求 巨大な複雑さに立ち向かう 48
49. 49. ドメイン駆動設計 現場で取り組むためのヒント 49
50. 50. 開発者がドメインを学ぶ モデルと実装を一致させる 深いモデルを探求する ドメイン駆動設計の基本活動 巨大な複雑さに立ち向かう 50
51. 51. オブジェクト指向 エクストリームプログラミング ドメイン駆動設計 Spring Integration Spring Batch Spring Security アプリケーションの基盤技術 51
52. 52. • 実践的なオブジェクト指向の考え方とやり方 • ドメインの知識をオブジェクトで表現する基本 • 「ドメイン駆動設計」本への橋渡し • 日本語版への序文 • はじめに • １部/２部/３部/４部の導入文 • 結論 52 • ３章 コードのいやな臭いと処方箋 • １２章 ４つの大きなリファクタリング • 第１部 多国通貨 • 値オブジェクトの設計の参考
53. 53. 分析からコードへの橋渡し • 全体を視覚的に俯瞰する実践的な技法 • 関連性から要点を導く • 要件（スコープ）を共通認識にする • 最小のステップでモデルをコードに落とし込 む実践的な技法 • 初期のドメインモデル • ユースケース記述 • ロバストネス分析（予備設計） 53
54. 54. 持続的な努力と到達レベル 到 達 レ ベ ル 努力（時間） 成果が出るまで がんばる期間 なかなか上達しなくても あきらめずにがんばる期間 学習曲線 もっと上を目指して がんばってみる期間 最初のブレークスルー 手ごたえを感じる瞬間 次のブレークスルー 気がついたらレベルアップ 別世界へのブレークスルー 視界が広がる瞬間 54
55. 55. • どんな状況でも改善はできる • どんなときでも「あなた」から改善を始められる • どんなときでも「今日」から改善を始められる 55 Kent Beck のメッセージ