Downloaded 101 times
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn.slidesharecdn.com/ss_thumbnails/2022-220117111455-thumbnail.jpg?width=640&height=640&fit=bounds)
ドメイン駆動設計のための Spring の上手な使い方
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. 対象領域（ドメイン）の知識を広げる • 業務の用語／言い回しを覚える • 登場人物、活動の目的、関心事、… •活動の内容、タイミング • ルール、前提、制約、… • 表面的な言葉の理解から始める • しだいに深い洞察へ • 背景にある構造や原理を言語化する • 継続的に学習する 9
- 10. 学んだことをコードで表現する • ドメインの知識をコードで表現する基本スキル • 値オブジェクト、コレクションオブジェクト、区分オブジェクト •識別オブジェクト、集約 • Repository, Factory • 知識の増加がコードに現れる • パッケージ名、クラス名、インタフェース名、メソッド名 • 洞察の深さがコードに現れる • パッケージの構造、オブジェクトの参照関係、… • コードレビュー：ドメインの学習成果のレビュー • パッケージ名、クラス名、インタフェース名、メソッド名、… • 参照関係／グルーピングの範囲 • コードで表現されたドメインの知識の量は？ 質は？ • コードでの知識表現に工夫の余地は？ 10 技術者はエクセルで知識を表現してはいけない
- 11.
- 12. モデル • 選び抜かれた重要な 側面 • 蒸留された本質的な知 識 •全体を形づくる主要な 骨組み 12
- 13. モデル • 選び抜かれた重要な 側面 • 蒸留された本質的な知 識 •全体を形づくる主要な 骨組み 実装 • 大量かつ網羅的な記 述が必要 • 重要ではないが、省略 はできない細部の記述 • 肥大化したコード、重 複したコードとの戦い 13
- 14. モデル • 選び抜かれた重要な 側面 • 蒸留された本質的な知 識 •全体を形づくる主要な 骨組み 実装 • 大量かつ網羅的な記 述が必要 • 重要ではないが、省略 はできない細部の記述 • 肥大化したコード、重 複したコードとの戦い モデルと実装を関連づけることで、実装が整理され、見通しが良くなる 実装からフィードバックすることで、モデルが実用的になる 14
- 15. モデルと実装を一致させる • ドメインの記述を、技術の関心事から独立させる • isolating-the-domain •Spring のプログラミングモデル • 概念の単位とプログラミングの単位を一致させる • オブジェクト指向によるモジュール化 • 型（クラス、インタフェース、enum）で、知識を表現する • 基本データ型ではなく、ユーザ定義型で表現する • 最初からぴったりの型は見つからない • 実験→フィードバック→設計の改善を繰り返す 15
- 16.
- 17. 深いモデルを探求する • 中核の複雑さ／機会に焦点を合わせる • 中核を探す活動 •仮説と検証 • 役に立つ型を見つけるための実験を繰り返す • 暗黙の概念を明示的に表現する • 暗黙になりがちな知識を明示的に表現する工夫 • しなやかな設計 • 複雑になっても成長を続けることができる設計 • 重複を徹底的に取り除く（オブジェクト指向設計） 17
- 18. 暗黙になりがちな知識を 明示的に表現する工夫 • 制約 • BeanValidationで、正しい値を明示的に表現する • Policy { Set<Predicate<T>> rules } • プロセス（業務の流れ／手順） • 流れの構造の表現 ： Set<Action>, Action#nextAction() • 行動の記録 ： List<Event> • 区分の分析 • enumによる区分名の列挙（コードから日本語名へ） • enumのリファクタリング • MECE : Mutually Exclusive and Collectively Exhaustive 相互に排他的、かつ、網羅的 • そうなっていない区分の背景を深掘る • enumに振る舞い（判断／加工／計算）を持たせる 暗黙の知識を宣言的に表現できると、if文がどんどん減っていく18
- 19.
- 20. 巨大な複雑さに立ち向かう • 戦略的に取り組む • 時間がかかる •地道な努力の積み重ねのエネルギー • モデルを探求する • このレベルでも、モデルとコードを一致させる • コードに責任を持つ開発者がリードする • 巨大な複雑さに立ち向かうためのスキル • 俯瞰 • 蒸留 • 大きな構造化 20
- 21.
- 22.
- 23. Spring のプログラミングモデル also knownas ドメインオブジェクト アノテーション Java-based configration application.properties 23
- 24. Spring のプログラミングモデル also knownas ドメインオブジェクト アノテーション Java-based configration application.properties ドメイン駆動設計の 活動の中心 24
- 25. Spring のプログラミングモデル also knownas ドメインオブジェクト アノテーション Java-based configration application.properties ドメイン駆動設計の 活動の中心 ドメイン駆動設計を実践した場合 何が変わるのか／変わらないのか 25
- 26. Springのプログラミングモデル Springはアプリケーションの「基盤」を提供する 開発者は、ドメイン固有のロジックに集中する ドメイン駆動設計の考え方そのもの focus on yourspecific domain model implement with plain Objects 26
- 27. Springのプログラミングモデル Springはアプリケーションの「基盤」を提供する 開発者は、ドメイン固有のロジックに集中する ドメイン駆動設計の考え方そのもの focus on yourspecific domain model implement with plain Objects DDD本が出版された後、Springドキュメントに、DDDを意識した記述が増えた @Service, @Repositoryは、DDD本に由来する エヴァンスは、EJBからSpringへのシフトは大きな転換だったと振り返っている Springは ドメイン駆動設計を実践するためのフレームワーク 27
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37. ドメイン駆動設計のための Spring の使い方 Spring IntegrationSpring Batch Spring Security 37
- 38.
- 39. 初日から、動くアプリケーションで考える 初日から、学んだことをコードで記録する 初日から、コードでモデルを表現してみる 初日から、End to Endで実験してみる gitですべての履歴を管理 spring-boot-starter-* 動く画面でフィードバック、実データからのフィードバック ドメインを学ぶ モデルと実装の一致 深いモデルの探求 巨大な複雑さに立ち向かう 39
- 40.
- 41. Spring Integration ドメインを学ぶ モデルと実装の一致 深いモデルの探求 巨大な複雑さに立ち向かう • 複数のアプリケーションの連携という課題 •境界づけられたコンテキスト（Bounded Context） • コンテキストマップ（Context Map） • モデルとモデルの連携パターン • EIP(Enterprise Integration Patterns)の実装技術 • メッセージングモデル • 分散／非同期／並列 • イベントソーシング • 結果整合性 githubリポジトリ 41
- 42.
- 43. Spring Integration • データ通信の技術vs. 業務モデル • メッセージングモデルは、業務のモデルでもある • ドメインの知識がコードに現れる場所 • message名/channel名/endpoint名 • コンポーネントの粒度、名前づけ、組み合わせ方 • Transformer • Filter • Router • Splitter/Aggregator • Scatter/Gather • Service Activator • Channel Adapter • 開発者のドメインへの意識/理解の違いが、設計（コー ド）にそのままでてくる 43
- 44.
- 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.
- 48. Spring Security • 認可モデル： 業務の重要な関心事 • できる／できない • 見える／見えない • 認可モデルを宣言的に明示する手段 • Role／権限 • Roleの分析と定義 • 権限の分析と定義 • UserとRoleの関係 • Roleと権限のひもづけ • RoleとRoleの構造化 ドメインを学ぶ モデルと実装の一致 深いモデルの探求 巨大な複雑さに立ち向かう 48
- 49.
- 50.
- 51. オブジェクト指向 エクストリームプログラミング ドメイン駆動設計 Spring Integration SpringBatch Spring Security アプリケーションの基盤技術 51
- 52. • 実践的なオブジェクト指向の考え方とやり方 • ドメインの知識をオブジェクトで表現する基本 •「ドメイン駆動設計」本への橋渡し • 日本語版への序文 • はじめに • １部/２部/３部/４部の導入文 • 結論 52 • ３章 コードのいやな臭いと処方箋 • １２章 ４つの大きなリファクタリング • 第１部 多国通貨 • 値オブジェクトの設計の参考
- 53. 分析からコードへの橋渡し • 全体を視覚的に俯瞰する実践的な技法 • 関連性から要点を導く •要件（スコープ）を共通認識にする • 最小のステップでモデルをコードに落とし込 む実践的な技法 • 初期のドメインモデル • ユースケース記述 • ロバストネス分析（予備設計） 53
- 54.
- 55. • どんな状況でも改善はできる • どんなときでも「あなた」から改善を始められる •どんなときでも「今日」から改善を始められる 55 Kent Beck のメッセージ