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