makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

「DDD Alliance! ドメイン駆動設計 RDRA for DDD ワークショップ!」に参加しました

2017/4/18 (火) 「DDD Alliance! ドメイン駆動設計 RDRA for DDD ワークショップ!」に参加してきました。

connpass
https://ddd-alliance.connpass.com/event/54308/

先日、「DDD Alliance! ドメイン駆動設計 RDRA Night!」」というイベントがありました。
そんとき書いたブログはこちら。


今回はその続編ということで、ワークショップを通じて実際に手を動かしてRDRAの勘所を体験する、というインベントです。
ブログを書いてネタバレにならないか、と神崎さんにお聞きした所、「問題ない」とのことだったので、自分の復習用にメモを書いてみる。

RDRAワークショップ


Rdra4 dddワークショップ from Zenji Kanzaki


ワークショップをやる前に、RDRAの概要について説明がありました。
前回イベントでもブログに書いたけど、今回もさらっとメモ。

要件定義には何を定義すればいいのか
  • 要件定義を「システムだけでなくシステムをとりまく環境」まで考える。

要件定義の構造を定義する
  • 何が定義されていないといけないのか。4つの視点で構造化する。
  1. システム価値、・・・ 価値を与えているものは何かを見る。人と外部システムをとらえる。価値は人がきめるので、誰がかかわるのか決める。
  2. システム外部環境 ・・・ どう使われるのか。システムの外部環境は、業務フローか、書けないならシーンを明確にする。
  3. システム境界 ・・・ 人と外部システムとの連携部分。
  4. システム ・・・ 機能とデータとドメイン構造を書く。
  • RDRAでは、モデルも状況によって使い分けするが、4つの視点は変わらない。
  • 視点ごとに作るモデルを省いたりする。

要件分析の枠組み
  • RDRAでは、4つは依存関係が大事。依存関係があるから要件が早く決まる。
  • 「システム」を決めるためには「システム境界」が決まってないといけないし、「システム境界」は「システム外部環境」が決まってないといけない。
  • 外側に視点をずらしていく。
  • 外側がWhyになっている。なぜ、はすべて外側にある。

コンテキストモデルからシステム境界まで
  • イベント ・・・ 外部システムとどういうやりとりをするのか
  • プロトコル ・・・ 状態遷移図
  • 「6.外部システムとのプロトコルを整理」では、はビジネス上認識しているユーザの状態を整理する。
    • オブジェクト指向のクラスではまだ見えてないので、それに対する状態遷移図ではない。
    • 「未出荷リスト」を出してくれ、という要求に対して、「未出荷」という状態を捉える。
  • 「7.ユースケースに関わるユーザーインタフェースを洗い出す」では、業務フローからユースケースが出てきて、それに画面をひっつけてインタフェースを出す。
    • 画面のレイアウト考えましょう、という話ではない。
    • 必要に応じて画面のラフスケッチを書く。
  • 「8.ユースケースを実現する機能を洗い出す」で、RDRA for DDDでは「機能モデル」はほとんど書かない。
  • 「9.アクションを機能に対応付ける」で、イベントを機能に結びつける。今回は機能はないのでやらない。
  • 「11.機能とデータを突き合わせる」で、機能とドメインを結ぶ。

RDRA for DDD
  • RDRA for DDDは深く分析する部分をdddにまかせている。
  • 「システム境界」は、ユースケースを中心に画面とイベントとアクターがくっついてる。

RDRA for DDD システム地図
  • 今回のワークショップでは、システム地図を作成する。1枚で全部書く。
  • システム地図を使って1枚で全部書くのと、RDRA for DDDで4領域を分けて書くのと、あんまりかわらない。
  • 4領域を全部ひっつけるとシステム地図になる。今回は時間がないので、システム地図を書く。


グループ演習:システム地図を作る


Rdra4 dddワークショップ from Zenji Kanzaki

今回は、実案件よりは簡単な題材でRDRAを実践してみるとのこと。
纏まったドキュメントを作る、というよりも、2時間で要求定義として形をまとめることが目的。
繋げてものを考えると、ある程度形になることを経験する。

今回は「RDRA Map Maker」というツールを使いました。
参加者にはツールのURLが公開され、3人1チームで、各チームにPC1台、このツールをインストールしました。

お題


  • 「会議室.com」という、会議室を貸したい人と借りたい人をつなぐサイトを作りましょう。
  • 貸会議室を営む会社から開発依頼を受けた想定で、マッチングビジネス用のサイトを開発する。
  • アクターに対する利用シーンを繋げて、情報まで洗い出すところまでやって完了。
20170419_rdra1.jpg

ホワイトボードの左にあるとおり、「アクター」から「情報」まで順に洗い出していきます。
  • アクター
  • 要求
  • 利用シーン
  • ユースケース
  • 外部システム
  • イベント
  • 画面
  • 情報




「アクター」と「要求」


うちのチームは「アクター」と「要求」は以下のように洗い出しました。
20170419_rdra2.jpg

アクターの洗い出しは比較的すんなりいったけど、ステークホルダーをどこまで考えればよいのかは気にする必要ありそう。
あと、「要求」は別画面に洗い出すように、との指示でした。この理由は後述の質疑応答にて。

「利用シーン」と「ユースケース」


利用シーンは「どういうふうに使えると嬉しいのか」を書くとのこと。
が、これが案外、難しい。どのチームも「利用シーン」を出すのに苦労してたようです。
というのも、この次の「ユースケース」との違いがわからなくて・・・ウチのチームも苦労しました。

神崎さん曰く、「利用シーン」より先に「ユースケース」を考えても問題ないとのこと。
「ユースケース」が安定すれば「利用シーン」はいらなくなるとのこと。
というわけで、うちのチームも「ユースケース」と「利用シーン」を同時に考えるように進めました。
20170419_rdra3.jpg
一番左が「アクター」、真ん中が「利用シーン」、一番右が「ユースケース」。

「外部システム」と「イベント」


次は外部システムを洗い出しました。
うちのチームでは、「認証システム」と「決済システム」を外部システムとしました。
次に、外部システムとユースケースをイベントで結びます。
「イベント」は「入金」と「認証」としました。
20170419_rdra4.jpg
赤枠が「外部システム」で、青枠が「イベント」。

「画面」と「情報」


最後に、「画面」と「情報」を分析します。

20170419_rdra5.jpg
20170419_rdra6.jpg

こんな感じで出来上がり。四苦八苦しながらもなんとなく形になりました。

発表


今回、3人チームで5チームあったので順に発表していき、随時、質疑応答がありました。
ピザとビールが届いたので、美味しく戴きながらの発表w
20170419_rdra7.jpg

質疑応答や意見交換で出た、神崎さんや増田さんや参加者からのコメントメモ。

図示する効果
  • 要求は網羅できない。なので、重要なやつだけ覚えておいて図にする。
  • 図を作ってるといろいろ見えてくる。
  • そうすると、「こうしよう」と決められる。

「要求」だけ別タブで設計した理由
  • 「要求」に戻って、「~~できること」と決める
  • 「要求」だけ違うシートに書いたのは、その要求でコントロールするため。
  • 要求を出していって、それでコントロールする。

オブジェクトを繋げる線
  • 矢印の向きは考慮しない。(考慮してもよいが)

ユースケース
  • 「利用シーン」と「ユースケース」の違いがしっくりこないという意見が多い印象。
  • 「予約をする人」と、「その予約を見ている人」は別のユースケース。

イベント
  • RDRAはシステムを使った仕事の単位で考える。
  • 「入出金」は入金と出金の両サイドあるが、自社の立場でどちらになるのかを考えるほうがよい。
  • UML的には外部システムをアクターと捉えることもあるけど、RDRAでは外部システムとアクターを分ける。
  • 「バッチ処理」とかは「手段」なので、RDRAの地図では表現しない。
  • 外部システムがイベントに繋がって、そのイベントがユースケースに繋がる。
  • イベントは外部のシステムの何とつながるのか、の「何と」を表す。

アクターとユースケースの間に利用シーンを挟むのは?
  • アクターとユースケースを直でつなぐのはあり。
  • ユースケースが安定してるなら、利用シーンはいらない。
  • ユースケースは「システム境界」。
  • れがまとまらないなら「システム外部環境」を置きましょう。それが利用シーンになる。
  • ユースケースを利用シーンより先に考えるチームが多い。
  • そのあとロジック洗い出しをする。計算ロジックとか判断ロジック。
  • ここまでに機能と情報は洗い出せてる。
  • どういうロジックが独自性なんだ、と探していく。

DDD
  • DDDはコアのロジックを探していく。
  • DDDはシステム全体をどうつくるか、というのにはフォーカスしてない。
  • RDRAで全体地図を作り、どこから攻め込むかを広く浅く見て、コアの部分をDDDで攻める。

情報
  • 最後に洗い出した「情報」は、DBテーブルやクラスではない。
  • 業務的な情報のこと。イメージは伝票。階層構造。

付箋の使用
  • 付箋で出すと発散方向に向かうので、どう収束させるか考える必要がある。
  • 線で結ぶ。
  • 粒度を決めたらそのままうまくいくか、というと、うまくいかない。
  • なのでとにかく出してみて、「このくらいの書きっぷりだね」と感じ取る。

網羅性
  • 画面中心だと、網羅しているか、とかわからない。
  • そいういうのをもうちょっと網羅してるとか、タイミングがどうあればいいのか、とか考え始めるとユースケースとか考えないと見えてこない。

シーケンス図ではダメなのか
  • シーケンス図とRDRAは対比できない。
  • シーケンス図はあんまり書かない。なぜなら、網羅してないから。
  • シーケンス図を書くくらいなら、状態遷移図を書くかな。

まとめ
  • 「画面」と「ユーザーストーリー」の関係を結びつけてみると、いろいろわかる。
  • とにかく繋げてみる。違う視点の要素をつなげてみる。
  • それをチェックするのはSIでもWebサービスでも価値がある。
  • 今回伝えたかったのは、「繋げると議論ができる」という点。
  • アクターとか利用シーンはシステム境界の外で、価値に関わる。
  • ユースケースとかはシステム境界。


そんなこんなで発表や質疑応答が22:00まで続きました。19:00開始なので、たっぷり3時間。

懇親会


発表会終了後、更にお菓子やおつまみも追加され、23:00頃まで懇親会。
美味しくいただきながら、神崎さんや増田さんといろいろ会話させていただきました。

感想


先日の講演ベースのイベントに加え、こーゆうワークショップが別に設けられ、手を動かす機会があるのは凄く良いですね。
短い時間ではありましたが、手と頭を使ってチームで意見交換しながら1つの成果物を作るのは良い経験になりました。
RDRAは初めてだったのでシステム地図の作成には四苦八苦しましたが、議論を重ねつつとりあえず書いてみると、いろいろ見えてきて、更に議論が活性化される。
線で繋ぐと異なる視点間の関係性が見えてきて、更に議論が活性化されます。




あと、図書館で本を借りてきました。

モデルベース要件定義テクニック
神崎 善司
秀和システム
売り上げランキング: 165,064


体系的に学ぶのと復習を兼ねて、読んでみたいと思います。

関係者の皆様、ありがとうございました。
スポンサーサイト
次のページ

FC2Ad