DDD をより駆動させるための ICONXプロセスとの付き合い方を紹介します。
BPStudy#151〜オブジェクト指向、モデリング、設計 LT大会[リモート開催] 2020/03/30
DDD時代に考えたいICONIXプロセスBPSTUDY#151〜オブジェクト指向、モデリング、設計 LT大会@hirodragon
View Slide
DDD時代に考えたいICONIXプロセス 2いつも時間内におさまりきらなくてごめんなさい
DDD時代に考えたいICONIXプロセス 3Today's TopicICONIX in the DDD eraMy Assumptions / PrerequisitesLooking for clues on DDD modelingI will talk aboutWhat`s ICONIX ?How to Use ICONIX in DDDI will NOT talk aboutWhat`s DDDICONIX Detail
DDD時代に考えたいICONIXプロセス 4My assumptions / PrerequisitesLooking for clues on DDD modelingDDDドメインを運用者と開発者がコミュニケーションをとりながら「モデル」育てるそして、そのモデルをソフトウェアとしてコードで表現する為の設計手法。戦略設計ドメインエキスパートと共にユビキタス言語を使いながらモデルを育てる戦術設計ドメインを表現したモデルをコードに落とし込む実装パターンやテクニック。またはその考え方
DDD時代に考えたいICONIXプロセス 5My assumptions / PrerequisitesLooking for clues on DDD modelingDDDドメインを運用者と開発者がコミュニケーションをとりながら「モデル」育てるそして、そのモデルをソフトウェアとしてコードで表現する為の設計手法。戦略設計ドメインエキスパートと共にユビキタス言語を使いながらモデルを育てる戦術設計ドメインを表現したモデルをコードに落とし込む実装パターンやテクニック。またはその考え方ここ難しくないですか?
DDD時代に考えたいICONIXプロセス 6要件定義 > 基本設計 > 詳細設計 > 実装 >UT > ITa(ITb) > (ST) > UAT一般的なシステム開発の流れ
DDD時代に考えたいICONIXプロセス 7要件定義 > 基本設計 > 詳細設計 > 実装 >UT > ITa(ITb) > (ST) > UAT一般的なシステム開発の流れ戦略設計ってどこからどこまで??なんとなくこの辺ぽい
DDD時代に考えたいICONIXプロセス 8I will talk aboutWhat`s ICONIX ?How to Use ICONIX in DDD今日はその辺のあまり話題にあがらない部分をフォーカスして、プロセスの例を紹介しようというお話です。
DDD時代に考えたいICONIXプロセス 9自己紹介林 宏勝Twitter : @hirodragon112株式会社ミライトデザイン CEO株式会社 Jocy CTOOOP/DDD/CQRS/ICONIX/Agile/PHP/RDRA/ペチオブ/OOCらへんが好きなサーバーサイドエンジニア上流から下流まで色々やります。
DDD時代に考えたいICONIXプロセス 10ICONIXプロセス
DDD時代に考えたいICONIXプロセス 11ダグ・ローゼンバーグマット・ステファン 著
DDD時代に考えたいICONIXプロセス 12ICONIXプロセスユースケースからソースコードを作るプロセス
DDD時代に考えたいICONIXプロセス 13ICONIXプロセスユースケース分析者は抽象的かつ本質的、技術に依存せず実装から独立したユースケースを書く序文よりアクター目線でこのシステムが何ができるのかを表している。当然裏でどのような言語、技術が使用されているかはスコープではない
DDD時代に考えたいICONIXプロセス 14ICONIXプロセスユースケース(開発者目線)不明瞭で曖昧、不完全で正しくない序文よりシステムがやりたい事はわかる。ただし、抽象的で具体的な方法論は記されていない。
DDD時代に考えたいICONIXプロセス 15ICONIXプロセスICONIXプロセスはそのギャップを埋める為のプロセス本質的ではあるが不明瞭なユースケースを具体的な実装に変換する為のフレームワーク
DDD時代に考えたいICONIXプロセス 16論理的には「理論」と「実際」に違いはない。しかし、実際には違いがある
DDD時代に考えたいICONIXプロセス 17ICONIXプロセス1. 要求2. 分析 / 予備レビュー3. 予備設計レビュー4. 詳細設計5. 詳細設計レビュー6. 実装
DDD時代に考えたいICONIXプロセス 18ICONIXプロセス1. 要求機能要求、ドメインモデリング、振る舞い要求(ドラフト版ユースケース作成)、要求レビュー2. 分析 / 予備レビューロバストネス分析、ドメインモデル更新、論理名付け、ドラフト版ユースケース修正3. 予備設計レビュー4. 詳細設計シーケンス図作成、ドメインモデル更新、静的モデル整理5. 詳細設計レビュー6. 実装コーディングと単体テスト、結合テストとシナリオテスト、次フェーズ準備
DDD時代に考えたいICONIXプロセス 19要件定義 > 基本設計 > 詳細設計 > 実装 >UT > ITa(ITb) > (ST) > UAT一般的なシステム開発の流れICONIXは開発の大半をカバーする
DDD時代に考えたいICONIXプロセス 20ICONIX in the DDD era
DDD時代に考えたいICONIXプロセス 21戦術的DDD→ わかりやすい戦術設計はオブジェクト指向のパターンなので開発者が理解しやすい調べれば答えが見つかりやすい集約, Entity, ValueObject 等々
戦略的DDD→ 難しい(く感じる)実装やツールの操作方法とは違い、実際のプロダクトの中にのみ答えがある。調べても正解がわからない。だから難しく感じるDDD時代に考えたいICONIXプロセス 22
DDD時代に考えたいICONIXプロセス 23例えば
DDD時代に考えたいICONIXプロセス 24戦略設計ドメインエキスパートと共にユビキタス言語を使いながらモデルを育てるモデルを育てるって?- ドメインモデリングって具体的にどうやる?- ドメインエキスパートと話せばモデルを作れる?ここが解決しない限りDDDなんてそもそも難しいよね?
DDD時代に考えたいICONIXプロセス 25ICONIX in the DDD era(3回目)
DDD時代に考えたいICONIXプロセス 26MDDDDDTDDRDRA等要件定義分析設計戦略設計戦術設計UTUCDD(ICONIX)これがないと、いきなり戦略設計をしても精度が悪い
DDD時代に考えたいICONIXプロセス 27ICONIXプロセス1. 要求機能要求、ドメインモデリング、振る舞い要求(ドラフト版ユースケース作成)、要求レビュー2. 分析 / 予備レビューロバストネス分析、ドメインモデル更新、論理名付け、ドラフト版ユースケース修正3. 予備設計レビュー4. 詳細設計シーケンス図作成、ドメインモデル更新、静的モデル整理5. 詳細設計レビュー6. 実装コーディングと単体テスト、結合テストとシナリオテスト、次フェーズ準備ICONIXの分析部分を取り入れるだけでもより効率的にDDDを回せるのでは
DDD時代に考えたいICONIXプロセス 28そろそろ時間なくなってますよね
DDD時代に考えたいICONIXプロセス 29要求ドメインモデリング (概念モデル DDDの文脈とは粒度が違うので注意)- プロジェクトの用語集- プロジェクトで実際に使われるすべての単語を辞書にする- 用語の洗い出しをしながら関連も洗い出す- システム目線ではない。現実世界に焦点を置く- ユースケースを洗い出す前に行う※ ユースケース駆動実践ガイドより引用
DDD時代に考えたいICONIXプロセス 30要求ユースケースモデリング (振舞要求)- 機能要求かをユースケースとドメインオブジェクトに割り当てる- 通常ケース代替ケースを考慮する- 関連に時間をかけない。何がおきているかにのみ着目する- アルゴリズムではない。アクターとシステムの対話ステップ※ ユースケース駆動実践ガイドより引用
DDD時代に考えたいICONIXプロセス 31要求要求レビュー- ドラフトユースケースが出来たタイミングで顧客の要求に合致しているかを確認する- ドメインモデリングが顧客のわかる言葉(ユビキタス言語)で作成されているか確認できる- スコープを明確にする- ユースケースから全ての要求が追跡できるかを確認する- ユーザーの望みがユースケースに網羅されているかを確認する
DDD時代に考えたいICONIXプロセス 32分析 / 予備レビューロバストネス分析- 分析でもあり設計でもある- ユースケースとオブジェクトを紐づける- 概念の発見- ユースケース記述からあいまいさを取り除く- ロバストネス分析中もユースケースの修正を行う- 関連線は気にしない- シーケンスではない※ ユースケース駆動実践ガイドより引用
DDD時代に考えたいICONIXプロセス 33分析 / 予備レビュー予備設計レビュー- ロバストネス図、ユースケース図、ドメインモデル図の辻褄があっているかを確認する- 代替コースが漏れていないかを確認する- 技術者以外(顧客等)双方が参加する
DDD時代に考えたいICONIXプロセス 34分析 / 予備レビューテクニカルアーキテクチャ- ここからでDDDの戦略設計に移行する- アーキテクチャ、パッケージ、コンポーネント等の選定- 要求をベースにアーキテクチャの選定ができる- 非機能要件等の考慮- テスタビリティ- コンテキストマップ
DDD時代に考えたいICONIXプロセス 35ICONIXプロセスを一部取り入れる事によりDDDはより駆動する
DDD時代に考えたいICONIXプロセス 36@hirodragon