DDD with RDRA, ICONIX

DDDを具体的なプロセスに落とし込むにはどういう観点が必要だろうか。
- 境界づけられたコンテキストがどこまでの範囲かよくわからない
- ユビキタス言語やドメインモデルをどのように発見すればいいかわからない。どこから着手すればいいのか？
- ドメインモデルがただのデータの入れ物になってしまう(貧血症)
という問いに答えるには、RDRA, ICONIXを検討するとよいというテーマの資料です。

Transcript

1. DDD with RDRA, ICONIX Junichi Kato (@j5ik2o)
2. 自己紹介 • Scala歴 6年 • サーバサイド開発・設計担当 • 最近やってること ◦ OAuth2周り
3. アジェンダ • Scalaでの実装技法は誰かがしゃべってく れるので、今日は「分析/設計」について フォーカスする。ということでScalaの話は でてきません:P • DDDを具体的な開発プロセスに落とし込 むにはどうしたらよいのか？ • DDDを知らなくても開発プロセス論として 聞いてもらってもよいです
4. クネビンフレームワーク • Simple(単純) ◦ 因果関係はすべて明白。「知覚 - 分類 - 対応」アプローチ。ベストプラクティスの適 用 • Complicated(煩雑) ◦ 因果関係の把握には分析もしくは何らか の調査、専門的知識が必要。「知覚 - 分析 - 対応」アプローチ。適切なプラクティスの 適用 • Complex(複雑) ◦ 因果関係の把握は振り返りによってのみ 可能であり、事前には不可能。「探査 - 知 覚 - 対応」アプローチ。プラクティスの出 現。 • Chaotic(カオス) ◦ システムレベルでの因果関係が存在しな い。「行動 - 知覚 - 対応」アプローチ。新た なプラクティスの発見。 ソフトウェア開発はこ ちらの傾向が強い 以降のスライドは、複雑な要件に対するアプローチです
5. DDDを実践する際の課題 • 実際の開発プロセスに落とし込むにはどうした らよいかわからない。 ◦ 境界づけられたコンテキストがどこまでの範囲かよくわ からない ◦ ユビキタス言語やドメインモデルをどのように発見すれ ばいいかわからない。どこから着手すればいいのか？ ◦ ドメインモデルがただのデータの入れ物になってしまう (貧血症) • 分析麻痺(完璧な分析→実装に進めない)では なく、十分に分析せずに実装するということに なってないでしょうか？(仮説)
6. • リレーションシップ要件駆動分析(RDRA) • ユーケース駆動開発(ICONIX) • ユーザーストーリーマッピング(USM) • 組織パターン • マイクロサービス 役に立つ開発手法を提唱している書籍 今日のスコープはここ。 すべてを取り上げることはできな いので、興味があれば本を読ん でみてください。
7. 注意事項: すべてのプラクティスを 適用すればよいということではなく、 観点を得ることが重要。 鵜呑みにせずに考えてみてください。
8. RDRAとは 網羅的で整合性のある要件定義をUMLの表現力 を使って、要件定義としてまとめる手法をリレーショ ンシップ駆動要件分析(RDRA)という。
9. RDRAの基本コンセプト • 網羅性 ◦ コンテキスト、システムの外部環境を捉え、システムが使われ る範囲を明らかする。そこからシステム要件を求めることで網 羅的に要件をまとめる。 • 整合性(今回紹介しないので興味があれば書籍を読んでください) ◦ システムの外部環境からシステムの要件までを複数の視点 からモデルとして表現する。各モデルの情報を関係づけるこ とで、情報の整合性を保つ。 • 表現力 ◦ 様々な視点から対象を表現することで多様な要求を構造的 に表現する。それを図的な表現としてUMLを使って表現す る。それにより議論しながらドキュメントを作成する。
10. 　要件定義の基本的な考え方 • システム価値 ◦ システムと関係を持つ対象と そこからの要求を捉える • システム外部環境 ◦ システムを取り巻く外部環境 を明らかにする • システム境界 ◦ システムの外部と内部の境 界線を明らかにし、システム の範囲を明確にする • システム ◦ システム内部の機能とデータ 構造を明らかにする システム (システムそ のもの) システム価値 (システムを使って生 み出す価値) システム外部環境 (システムを取り巻く環境 ) システム境界 (システムとの接点 ) 4つの価値は強い依存関係があり、 システムを語るには、これらの要素 は不可欠となる。
11. 要件定義のための4つの領域 システム システム価値 システム外部環境 システム境界 ドメイン モデル ドメイン モデル ドメイン モデル 外部システム イベント ユースケース 情報 情報 業務フロー/ 利用シーン
12. RDRAのモデルを利用する • 関係者と合意を取りながら「どのようなシステム を構築するのか」ということを分析し、明確にシ ステムのイメージに落とし込むことが重要。 • その際に必要となるのは、アイデアの表現手段 としてのモデル(RDRAのモデル)。モデルを通じ て現状把握→共通認識→議論→合意形成とい うプロセスを踏むことができる。 あたり前のように聞こえるが、あなたの常識がチームの常識 とは限らない。RDRAは認識齟齬を埋めるための形式的手 法です。
13. ドキュメント作成＝要件定義ではない • 要件定義は、ドキュメントを作成することを目的 としない。対象を分析・定義することでシステム の要件を固めていく作業。ドキュメントはその知 識を共有するために利用する手段。 • 以下の2点の観点が必要。 ◦ システムが対象とする利用シーンの範囲 ◦ 段階的にシステム要件につなげる道筋
14. イベント告知サイトの例
15. システム価値 システムと関係を持つ利害関係者や外部システ ム、およびシステムに対する要求を洗い出す
16. コンテキストモデル • システムへの要求を発生させる 元となる利害関係者・外部シス テムを洗い出すためにコンテキ ストモデルを作成する。開発時 と運用時の両面で考える。図を 分けてもよい。 • このシステムに対して要望・要 求を持つと考えられる、経営者 は間接的なつながりを示す。 • アクターはヒアリング対象。後の プロセスで、役割・責務を明確 にしていく。アクターの種類が多 い場合は汎化を検討する。
17. 要求モデル • 各アクターが持っている、機能要 求・非機能要求を洗い出す • 要望→要求→要件 ◦ 要望: こうできたらいいなとい う思いつきレベル ◦ 要求: 検討対象として合意さ れているもの ◦ 要件: 開発対象として合意さ れているもの • 開発者は機能に関心が向かいが ち。機能の根源となる要求を整理 することは整合性の取れたシステ ムを作るために必要 • USMでいうところのバックボーン の洗い出し
18. システム外部環境 システムを取り巻く外部環境として、業務フロー・利 用シーン、および関連する概念をモデル化する
19. 利用シーン • 汎用的に利用されるツールやサービスなどの提供を目的にする場合は、利用シーン を利害関係者別に整理する(特定の業務が対象であれば、業務フロー)。 • システムがどのような場面で利用され、どのような価値を生み出すかを捉える。 • USMのバックボーンに相当
20. 概念モデル • 対象となる業務でどんな用語 や概念が使われているか整理 する。 • 合意形成するには、共通の概 念が欠如していては不可能。 同じ用語でも文脈が違えば、 目的が変わる可能性がありま す。中古車販売会社と自動車 修理工場では、「車」に対する とらえ方が変わるなど。議論 がかみ合わない場合は、まず 概念の整理が必要。 • ICONIXでも補強できる
21. システム境界 システム内部と外部の境界に位置するものとして、 ユースケース、画面・帳票、プロトコル・イベントな どを明らかにする
22. ユースケースモデル • システム化する範囲はど こまでか。システムとの接 点はどのようになるのか を明確にする • それを明確にするため、 ユースケースモデルを作 成する。ユースケースを 人間とシステムとの対話 に関する範囲に限定す る。 • 洗い出しにはUSM, 分析 にはICONIXでの補強を お勧めします
23. 画面/帳票モデル • 画面・帳票が種類や主要な項目などを洗い出す。ユースケー スと紐付いてなければならない。 • (所見)ホワイトボードのラフなスケッチやペーパープロトタイプ でもよい気がする。
24. プロトコル/イベントモデル • 外部システムからのイベントや、外 部システムとのインターフェイスを洗 い出しルール化する。 • 外部システムとの連携は、人間が相 手ではないので、状態マシン図を使 用してモデル化できる。 • データのライフサイクルや条件に よって有効・無効になる機能がある 場合はこの手法で整理する。 • ここでいう状態とは外部システムと当 該システムの両方、相互作用を表し たものになる。
25. システム 最後にシステムの内部構造を明らかにする。デー タモデルもしくはドメインモデル、機能モデル、ビジ ネスルールを作成する
26. ドメインモデル • システム化対象領域の概念(知 識)をソフトウェア構造にマッピン グし、その概念構造をシステム 上に再現することが目的 • システムに対する要求や変更 はビジネス上の概念から発生す るので、その概念がシステム上 に存在することでシステムが理 解しやすくなる • 右図のようなドメインモデルには 最初から到達しない。ブレストの 中で違和感を排除しながら、合 意形成する必要がある。 • ICONIX, Eric本での補強をお 勧めする
27. 機能モデル • 機能がどのユースケース、画面・帳票、イベント、ドメインイベント関係するか を表したモデル。
28. ICONIXとは RUP, XPなどのアジャイルソフ トウェア開発よりも前から存在 するソフトウェア開発方法論の 一つ。UMLのユースケース駆 動だが、RUPより軽量。以下の ４つのマイルストーンがある • 要求定義 ◦ 要求レビュー • 分析/概念設計/テクニカル アーキテクチャ ◦ 予備設計レビュー • 設計/コーディング ◦ 詳細設計レビュー • テスト/要求の追跡 ◦ 配置
29. 要求定義 • 要求レビューまでにやること • まず、ドメインモデルから洗い出す ◦ 多重度などは意識せず用語からド メインモデル候補を探索して図にす る。ただし不完全なものと仮定して いる • なぜユースケースが先ではないのか、 ユースケースはドメインモデルの用語を 使って記述されるべきだから。モデルの 静的な部分と動的な部分を結びつける ことができる。 • 要求が明らかになっていればこの手法 でよいが、不明瞭であればRDRAのシ ステム価値に基づき、利害関係者と外 部システムを洗い出し、要望を要求とし て蒸留した方がよいと考える。
30. ドメインモデリング • 考えられる用語を列挙。ほとんどが同じ概念を指 す言葉として使われている。そのままシステム化 すると混乱のもと。用語を洗い出しながら排除する ◦ モデルとしてのユーザとユーザアカウントの 違いは？ユーザアカウントはエンティティだ が、ユーザはアクターです。 ◦ グループリストとコミュニティリストは、同じも のなのでどちらかに決める。コミュニティリス トに決定 ◦ イベントの検索キーワードはUI要素。責務が 異なるのでそんなことはやめましょう。タグと 命名する。 • 用語リストから、最初のドメインモデル (静的)を作 る。 ◦ 集約(has-a), 汎化(is-a)のみの表現。属性・ 振る舞い、多重度はこの段階では早すぎる。 分析が終わってからにしましょう。 不完全と仮定し、分析麻痺 を回避する 用語リスト 初期のドメインモデルを作る
31. ドメインモデルを発見する • チームでブレストを行うと、新たなドメインモデルを発見することもある。 • 無料はもちろん、有料の場合はクレジットカードで決済できるようにしたい → では、イベントプランと、ユーザアカウントにはクレジットカードというドメイ ンモデルが必要！ • まだ、曖昧なところがたくさん！ドメインモデルを精査するには、声に出して みること。”ユーザアカウントはクレジットカードを持っている”。それに、違和 感がなければ役に立つモデルである 静的な側面 しか扱ってい ないことに注 意！
32. ドメインモデルを探求する • 次のブレストで、主催者アカウントと参加者アカウントは、独立して検索される エンティティ(集約)だろうか。あれ、なにかがおかしい！ • そのイベントの主催者や参加者が誰かということだけに関心がある。現状のま まだと、イベントを手に入れても誰が主催者か参加者かわからない。これは分 析と設計を分離したモデルでは！あれ、コミュニティがないとイベントが作れな いか、独立に作れるのかわからない。あいまい！ • 最終的に、is-aではなくhas-aを利用した以下のモデルにたどり着いた
33. ユースケースモデリング • ICONIXでは、ユースケースによって システムが駆動する。つまり、ユース ケースが設計駆動することを意識す る。実際には、全ユースケースに対 して、シーケンス図を起こすことにな る。 • ユースケースをドメインオブジェクト に紐付ける。ユースケース駆動のオ ブジェクト指向設計を実現する (RDRAの機能モデルと同様) • ドメインモデルの名前を使って、ユー スケース図を書く。 • 洗い出したユースケースの規模が大 きい場合グルーピングする。図をき れいにするコストは掛けてはならな い。ユースケースの依存関係も整理 していく。 アクター・ユースケース・ ドメインモデルつながり を網羅することが重要
34. • 肝心なのはユースケースの内容＝ユースケース記述 ◦ 「動詞＋れる/られる」などの、指示的な記述をしてはならない。 ◦ 叙述(じょじゅつ)的な記述にすること。 • 指示的な記述 ◦ 「ユーザは、ユーザ名とパスワードを使った認証方式でログインできる」 • 叙述的な記述 ◦ 「ユーザは ユーザ名とパスワードを入力して、「 ログイン」ボタン をクリッ クする。システムはユーザ名からユーザの情報を取り出し、パスワード をチェックする。そして、ユーザはシステムにログインする」 • 述べるのではなく示す ◦ 述べるだけだと、ソフトウェアの重要な振る舞いが隠されてしまう ◦ 述べるのではなく、ログインに含まれる手順を示すことが重要。 叙述的なユースケースを書く
35. • 外側から内側の対話を意識する ◦ アクターとシステムの対話(外側から内側の対話)が示されていること。必要 に応じて、GUIモックアップを書く。 • ユースケース記述を、BCE(Boundary-Control-Entity)ステレオタイプで表現す る。 ◦ 名詞は、ドメインオブジェクトか、バウンダリオブジェクトになる。 ◦ 動詞は、オブジェクト間のメッセージです。これは実装すべきソフトウェア機 能(コントロール)を示している。 システム境界とBCEステレオタイプ アクター システム アクション 応答 システム境界 エンティティ (ドメインオブジェクト ) バウンダリ コントロール (メッセージ) 名詞(オブジェクト) 動詞(処理) ロバストネス分析の前提となる
36. • ユースケース ◦ イベントに参加する • 基本コース ◦ ユーザはイベントページへのリンクをクリックする。システムはイベントを 取得し、それを表示する。それから、ユーザは参加ボタンをクリックする。 システムは、そのイベントに参加者として登録する。 • 代替コース ◦ 参加者枠がない場合：システムは、そのイベントに補欠者として登録す る。 ユースケース記述の例 • ユースケース記述を短く書く。ユースケースの外部は書かない。イベントの表 示に関することのみに集中する • ユースケースの範囲外の記述になりやすいため、事前条件と事後条件を排除 する。<<precedes>>関係でユースケースの順番を示す。 • ドメインモデルに直接ユースケースを結びつけるため、ユビキタス言語を使っ て表現すること
37. • プロジェクトの用語(ユビキタス言語)で構成されたドメインオブジェクト を使って、ユースケースを記述する ◦ 曖昧な例 ▪ ユーザはイベントページへのリンクをクリックする。システムは イベントを取得し、それを表示する。それから、ユーザは参加 ボタンをクリックする。システムは、そのユーザが参加を希望 するイベントに参加予定のユーザとして登録する。 • ユースケース記述にバウンダリの用語を使う ◦ 「システムは、ウェブページを表示する」では曖昧すぎる。「システ ムは、イベント一覧ページを表示する」とするべき。「システムは、 イベントカテゴリに基づくイベントリストを含むイベント一覧ページ を表示する」とするとさらに明確になる。 ユースケースにユビキタス言語を使う
38. • ユースケースからコードに落とし込むには、ユースケースをドメインオブジェ クトに関連づける必要がある。そのために、ロバストネス分析を行う。ロバス トネス図は、ユースケースをオブジェクトの絵として表現したもの。 • ロバストネス分析では、ユースケース記述を分析し、最初のオブジェクト群 (バウンダリ、ドメインオブジェクト、コントローラの三種類)を推定する。 分析/概念設計/テクニカルアーキテクチャ 何をどのように？ ロバストネス分析の目的
39. • 名詞 ー 動詞 ー 名詞 の形式でユースケース記述をパターン化する ◦ 結合ルール ▪ 名詞は動詞とつなぐことができる(逆もまた同様) ▪ 名詞を他の名詞につなぐことができない ▪ 動詞は他の動詞とつなぐことができる ロバストネス分析
40. • ユースケース記述の精査が終わると詳細設計に移る。 • ユースケース記述で洗い出したした、アクターとBCEを中心とし たシーケンス図を作成する • 通常とは異なる記法を利用します。 ◦ シーケンス図上には、ユースケース記述に登場したコント ロールが存在しない(責務があれば存在してもよい)。代わり に、コントロールはエンティティなどのオブジェクトへのメッ セージに置き換えられます。 ◦ このシーケンス図ではオブジェクトの動的な側面を分析する ためであり、一般のシーケンス図のように手順の詳細を説 明するものではありません。このため、活性区間も扱いませ ん。 設計/コーディング
41. シーケンス図を書き始める • ロバストネス図から、そのまま持ってくる • この段階では、まだエンティティには振る舞いがない (静的なドメインモデルであるため) • シーケンス図を描くことで、動的な側面を分析し、エン ティティに振る舞いを割り当てる
42. エンティティに振る舞いを割り当てる • どのコントロールをエンティティに割り当てるべきかを 考える ◦ そのエンティティとは何か？ ◦ その操作は、どのクラスの責務(アクション、情報保 持、判断)となるべきか？ • オブジェクトデザインの格言 ◦ ”責務は、ユースケース中のシステムの振る舞いに 関する記述文やそこに暗示されているものから見 つかる” ◦ “責務は、ユースケースや他のシステム記述に内在 する抜けを埋めることでさらに見つかる”
43. やかんをただの物体とみるか否か • 物理的なオブジェクトは、仕事を行うか、情報を保持するだけで 判断は行わない。電話帳オブジェクトは何も行わない。一方、 サーモスタットは判断を行い、制御信号を送信する。やかんも 容器の役割ぐらいしかない。しかし、分析によってどのような責 務を与えるかで変わってくる • Alexanderが考えるやかんの責務 ◦ 水をこぼしたり、しぶきをあげたりせずに中身を注ぐ ◦ 水を漏らすことがなく、沸騰するまで暖めることができる ◦ 水の沸騰を知らせる ◦ 安全な方法で運ぶための便利な手段を提供する これらの洞察によって、平凡な貧血症オブジェクトになるか、ドメイ ンリッチなオブジェクトになるかが決定づけられる
44. BCEだけは十分に分析できない場合 • ロールステレオタイプ ◦ 情報保持役(Information Holder)は、情報を知り情報を提供する ◦ サービス提供役(Service Provider)は、仕事を行うが一般に演算サービスを提供する ◦ 構造役(Structrer)は、オブジェクト間の関係と、それらの関係についての情報を維持する ◦ インターフェイス役(Interfacer)は、システム内の異なる部分間で情報やリクエストを変換す る ◦ 調整役(Coordinator)は、他のオブジェクトにタスクを委譲することでイベントに対応する ◦ 制御役(Controller)は、判断を行い他のオブジェクトのアクションを指示する エンティティ、値オブジェクト 情報保持役、構造役 ビュー インターフェイス役 コントローラ 調整役、制御役 ドメインサービス サービス提供役 アプリケーションサービス 調整役、制御役 リポジトリ インターフェイス役 ファクトリ 調整役
45. 最終的なユースケース • フレームワークを意識し てオブジェクトを見つけ る • コントロールをエンティ ティへのメッセージに変 える • ドメインモデルやユース ケースに不備があれ ば、フィードバックする
46. • RDRAでは、システム価値＞システム外部環境＞システム境界＞ システムの階層を使って、要件を捉えていくことに意味がある。 ◦ コンテキストモデル、要求モデル、利用シーンはICONIXにはな い考え方。境界づけられたコンテキストがどのようなものかを理 解する助けになる。 ◦ システム境界を跨がる際にプロトコルモデル/イベントモデルの 観点は、アーキテクチャ設計を支援する。 • ICONIXでは、ユビキタス言語で構成されたユースケース駆動によ るオブジェクト指向設計を実現することに意味がある。 ◦ ドメインモデリングとユースケースモデリングはドメインモデルの 蒸留と実現するべきソフトウェア機能を具体的に洗い出す ◦ ロバストネス分析によって、静的なドメインモデルに動的な側面 を付け加えていくことができる。 RDRA, ICONIXの特徴
47. 統合するためのヒント システム価値 システム 外部環境 システム 境界 システム ユースケースモデル 概念モデル ドメインモデル 要求定義 分析/概念設計 /アーキテク チャ 設計 ドメインモデリング ユースケース モデリング (ユースケース記述含む ) ロバストネス分析 不完全と仮定 振り返る シーケンス図 利用シーン コンテキスト モデル 要求モデル 画面/帳票モデル プロトコル/ イベントモデル 必要最低限のものを選ぶ データモデル ”何をどのように”のギャップを埋める 機能モデル 振り返る 「探査 - 知覚 - 対応」のためのプロ セスと捉えると両者を統合すること ができる。つまり、振り返りこそが 重要。
48. • すべてを適用すると開発プロセスが重くなるのは自明。何も考えず に網羅的に実践するのは現実的ではない。ただ、観点だけは抑え ておこう • 必要に応じて、プラクティスを選択することが重要 • ただし、重要なものを外さないこと。以下を基本の軸にしてみてはど うだろうか ◦ コンテキストモデル (RDRA) ◦ 要求モデル (RDRA) ◦ ドメインモデリング (RDRA/ICONIX) ◦ ユースケースモデリング (RDRA/ICONIX) ◦ ロバストネス分析 (ICONIX) ◦ シーケンスモデル (ICONIX) • さらに簡単な部分ではなく、重要で複雑な部分から着手するとよい かもしれない。 まとめ 利害関係者と共に 動的な側面をフィードバック
49. ご静聴ありがとうございました。