fc2ブログ

makopi23のブログ

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

「DDD Alliance! ドメイン駆動設計 RDRA Night!」に参加しました

2017/4/12(水) 「DDD Alliance! ドメイン駆動設計 RDRA Night!」に参加してきました。

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

Togetter
https://togetter.com/li/1100299

DDDの勉強会、立て続けですね。先日の勉強会もブログにメモ書いたところでした。


DDDは読書会や勉強会にいろいろ参加したりと、それなりに知識あったのですが、RDRAというのは今回が初見でした。
以下、自分の復習用メモ。

ドメイン駆動設計：分析しながら設計する


ドメイン駆動設計　分析しながら設計する from 亨 増田


増田さんのDDDの講演は何度も聴講させていただいてますが、今回は

DDD + RDRA + ICONIX

という新しい切り口が登場していました。
私も最近までICONIXの読書会に参加してましたので、この３つの並びは新鮮でしたね。



DDDとICONIXはそれなりに知識がありましたが、RDRAは今回が初めてでとても興味深いのでした。
そしてまさかのドラクエ（笑

RDRA for DDD　「開発をリズミカルに回すための安定した要件出し」


Rdra4 ddd from Zenji Kanzaki


RDRAは「ラドラ」と発音するそうな。
以下、スライドに書いてない口頭説明を中心にメモ。

RDRAができた背景
  • ガンドチャートを書くと、時系列の左側にタスクが圧縮されて、膨らんでしまう。
  • ガントチャートを書くと誰が何をやればいいのか早くわかるので、それで早い段階から個人ワークが始まってしまう。
  • それで、どんどんドキュメントができていき、変更できなくなる。

RDRAとドメインモデルの関係
  • RDRAは全体を俯瞰する。地図を書く。
  • RDRAは外から攻め、DDDは中から攻める。

RDRAで枠組みを決める
  • モデルをタイムボックスで育てていくのがRDRA。

要件定義には何を定義すればいいのか
  • 「システムを取り巻く環境」と「システム」の２つ。
  • 「システムを取り巻く環境」についても定義しないと、細かい設計ができない。

要件定義では何が定義されていないといけないのか
  • システムに価値を与えるものを明らかにする

要件定義の構造を定義する
  • 要件定義の構造は以下４つ。
  1. システム価値
  2. システム外部環境
  3. システム境界
  4. システム
  • ４つの視点で、何を定義すればいいかが決まってくる。

要件分析の枠組み　構成要素
  • RDRAのキモは、依存関係がある点に着目すること。
  • 決め方が決まってないと早く決まらない。依存の関係性を使って決めていく。
  • システム境界の認識がぶれてるのにシステムの話をしてもぜんぜん意見はまとまらない。
  • なのでシステム境界から話しましょう。
  • 依存の方向を内側から外側へ、Whyを辿る。
  • 依存性を辿ると、なぜそれが必要なの？がわかってくる。

コンテキストモデルからシステム境界まで
  • １．対象業務に関わる人や連携システムを把握する。
  • ２．ステークホルダーの重要な要求を掴んでいるかが重要。細かな要求はそれほど整理しない。
  • ３．業務フローは時間かかるので、まじめに書かない。ざっくり書く。
    • 業務改善を目的にしてるなら業務フローをしっかり書くかも。
    • そうじゃなければ、どうシステムが使われるかが分かるくらいでよい。
  • ４．ユースケース図を書くにはツール使うことを想定している。
  • ５．外部システムとのイベントを捉える。外部システムと何をやるのかを整理する
    • 例えば、バッチプログラムの一覧があった時、それらを「バッチ」と一括りにしないこと。
    • あのバッチはシステム連携をやってるんだ、とちゃんと認識すること。
  • ７．ユースケースはシステム境界と捉える。ここで言うユースケースは、UMLのユースケースとはちょと違う。
  • ９．プロトコル＝状態遷移
    • システムのふるまいをhowでなく業務として、何によって遷移するのかを考えていく。
    • 未出荷→出荷、は遷移で表現される。
  • １０．データモデルはER図とかとは違う。データモデルを一番最後に作るわけではない。
  • １１．機能複合モデルは必ずしも書くものではない。

すべの情報をつなげる
  • つながっていることが重要。依存関係がある。
  • ぜんぶ繋がってる。この分析を短期間に回す。
  • まったく新規のシステムでもない限り、全てをつなげた図をざくっと直すのはそれほど時間かからない。
  • いったん形を書いて、おぼろげでも全体像をつかむ。つながっていることがすごく大事。
  • １個１個を完成させるアプローチはとらない。
  • 既存システムの場合は、左から右へ、ではなく、できるところから積み上げていったりする。
  • プロジェクトの状況にあわせてボトムアップに埋めることもある。

各要素がつなげる
  • 各構成要素は繋がってる。膨大な情報を扱っているわけではない。
  • すべての情報をつなげて、網羅性と整合性を確保する。

RDRA for DDD
  • 普通のRDRAに比べ、定義するものがぐっと減る。
  • 「システム価値」から「システム境界」までをRDRAでやる。「システム」より先はDDDにまかせる。
  • 「業務フロー」か「利用シーン」のどちらかで「システム外部環境」を書く。
  • 「システム境界」でユースケースを置いて、イベントなどを紐付けていく。
  • 「システム」のとこはビジネス的にいうと「伝票」。構造化もしない。構造化はドメインモデルにまかせる。
  • なので「システム」のとこは書いても書かなくてもいい。

要求側と開発側でのモデルイメージ
  • 上の要求側のモデルは、俯瞰する形ですらっと作る。広く浅く分析するためのモデル。
  • 下の開発側のモデルは、深く分析するためのモデルで、DDDと役割分担する。

要求側と開発側の関わりイメージ
  • 深いことやろうとすると業務側の知識が必要となる。
  • 密にコミュニケーションしてドメインモデルを作成する。
  • 要求側と開発側でスキルセットは違う。
  • RDRA自体は開発方法を規定していない。Howは使わない。
  • 「システム境界」までははっきりさせて、あとはDDDで回しましょう。

変化に耐えられる軸
  • DDDとRDRAで役割分担する。
  • RDRAは要件定義の軸をずっと維持する。ブレない軸として使っていく。
  • 開発の軸はドメインモデル。DDD。

網羅はすべてを洗い出すことではない
  • RDRAの網羅は、重要なものをほぼぼぼ捉えたら、網羅されたものとする。
  • モデルを書きながら重要なものを識別する。
  • イテレーションで回していくので、全体を俯瞰してどういう分割になるのか、なんらかの分割単位が見えて、どこから攻めればいいかが見えることが大事。

頭の中を可視化
  • メンバーの頭の中にあるものを可視化する。
  • 図におこして議論しましょう。
  • 一覧を作って１行１行を担当者に振り分けて作業する、というWBSの常道をやると、詳細が埋もれてしまう。
  • それで、全体像を誰も説明できない、という状態になる。個人の頭の中やドキュメントに散在してしまう。
  • RDRAは広く浅く、早くまわしていく。

RDRAの弱点
  • RDRAはシンプルに表現できるけど、ビジネスルールやデータ構造は、つぶつぶの中に内包される。
  • ビジネスルール等の具体的な複雑度がみえにくい。
  • ビジネスルールの抽出はモデリングするだけではキツイかな、と思ってる。

Q&A
  • Q：コンテキストモデルとは？
  • A：このシステムに登場するのは誰で、どんなシステムとつながるんですが、を表現する。

議論しながら先に進める。少人数で決めて進めていったほうが早い。
人を増やして局所的にWBSの１つを振っていくのは、全体像がわからないので結局うまく考えられない。


モデルが導く要件定義、文章が導くプログラミング


モデルが導く要件定義、文章が導くプログラミング—ソフトウェア開発戦略Docs.com


ソフトウェア開発戦略
  • トレースは非常に大事。ばらばらの情報ではトレースできない。

基本的なワークフロー
  • まず「コンテキストモデル」を作る。さっとつくる。完璧は求めない。
  • 「要求モデル」もまとめる。
  • この段階で荒いけど「ドメインモデル」を書き始める。
  • この３つで何をしたいかというと、スケジュール感や費用感を出したい。
  • ソフトウェアの価値は、ここまでの分析の段階で既に認識されている。
  • 見積もりをして全体計画に落とす。
  • ここまでが静的。そのあと動的な「業務モデル」を作っていく。
  • 問題領域には「もの」と「こと」があって、「動的」と「静的」な側面がある。
  • ①～④の４つの象限を、対応するモデルにあてはめる。
  • 常にトレースすることによって整合性や網羅性を確保する。
  • 究極的にはユースケースモデルを作る。ここにはユースケースシナリオも入る。
  • ユースケースがそろうとロバストネス分析まで組み込む。
  • ぐるぐる回しながら広く浅く進めていく。RDRAの基本的な考え方を使う。
  • モデルだけじゃよくわかんないので、コードを書いちゃう。プロトタイプを作る。
  • ざっくりコードを書いて検討する。そのコードは開発に使っていく。こんなかんじで上流工程を回す。

コンテキストモデル
  • コンテキストモデルを使い、どういう利害関係者がいるか、関係ない人もはっきりさせる。

ドメインモデル
  • 初期のドメインモデルには、大きな四角もある。スケッチの段階。
  • コンテキストモデルとドメインモデルをスライドに表示しながらユーザと話すと、いろんな話ができて、業務知識を吸収できる。
  • 業務フローだとユーザは混乱する。条件分岐ばっかで、どのくらいの頻度で起きるのかが分からない。
  • ユースケースの「晴れの日シナリオ」をユーザと話すべき。余計な条件分岐をユーザに考えさせない。
  • 議論を重ねるとユーザの頭の中が整理できるので、そのあと業務フローに入っていく。

モデルで導く要件定義（あるいは上流工程）だと、何がいいの？
  • 縦軸が抽象度。抽象度は人によっても集約されていく。経営者、マネジメント層、現場、で抽象度は違う。
  • プレイヤーに応じた抽象レベルを使い分けて説明することが大事。
  • 抽象的なものを具体化していく変換作業が必要。
  • 抽象度が高いものはモデルが得意。逆に、具体的なものを語るには文章が得意。
  • モデルと文章の使い分けが抽象度のコントロール。
  • 抽象レベルはできるだけ合わせたほうがいい。

文章が導くプログラミング
  • 業務の言葉を日本語化したまま、プログラミングする。
  • 「ドメイン＝知識」だと思っている。業務の中に知識がある。知識は言葉で語られる。
  • その言葉を共有し話ができれば素晴らしいソフトウェアができると思ってるので、言葉が大事だと思っている。
  • 日本語だとタイポが増えそう。文字も長くなる。Visual Studioだと日本語でもインテリセンスが効く。


感想


DDD、RDRA、ICONIX、RDRA for DDD、文章が導くプログラミングと、RDRAを中心に多岐にわたるネタでした。
特にRDRAは初だったのですが、ワークショップも今度あるようです。こちらも参加予定。


やっぱやってみないとわからないところもあるので、座学とワークショップがセットになっているのは良いですね～

関係者の皆様、ありがとうございました。

-->