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


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

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

「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の読書会に参加してましたので、この3つの並びは新鮮でしたね。



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

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


Rdra4 ddd from Zenji Kanzaki


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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



感想


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


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

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

「JSUG勉強会 2017年その3 ~ ドメイン駆動設計 powered by Spring」に参加しました

2017/3/28(火) 「JSUG勉強会 2017年その3 ~ ドメイン駆動設計 powered by Spring」に参加してきました。

DoorKeeper
https://jsug.doorkeeper.jp/events/58637

DDDやICONIXの読書会に参加しつつ仕事でSpringを触っている私にとって、このイベントはとてもピンポイントで、とても楽しみでした。
増田さんの講演は何回も聞きに行ってますが、毎回新しい発見があります。

以下、講演中に取った自分復習用のメモ。


講演:ドメインロジックに集中せよ


ドメインロジックに集中せよ 〜ドメイン駆動設計 powered by Spring from 亨 増田


モデルに基づき設計する
  • モデルを使わない開発プロセスの場合、バックログ(機能一覧)に沿って消化していく。木をブレークダウンしていく。
  • これはドメインモデルの考え方ではない。
  • 開発プロセスにモデリングを1つ入れると、全体の見通しがよくなる。
  • モデルが無いと、羅針盤・地図が無い状態で開発することになる。
  • モデルを使うことが複雑さに立ち向かうことに効果がある。
  • モデルを作ればドキュメントがいらなくなる、ということではない。

インクリメンタルに開発する
  • 開発メンバは情報収集から分析、設計、実装、運用まで全部やる。
  • day-1のうちからとにかく動かす。Spring Bootを使えばすばやく立ち上げられる。


アンチパターン
  • プレゼンテーション層やデータ層にロジックがはいる。
  • ドメインロジックは3層にばら撒かれがち。
  • これもSpringの1つの使い方ではあるが。。。

ドメインモデル
  • ドメインモデルはPoEAA(エンタープライズ アプリケーションアーキテクチャパターン)から来ている。
  • ドメインモデルは、振る舞いとデータが一緒にある。
  • 巷のOOはgetter/setterだけを持ったデータクラスとか設けるほうが一般的だが、DDDはそうじゃない。
  • ドメインモデルの利点は、変更が楽で安全になること。

トランザクションスクリプト
  • 機能一覧を作って分担して各自作り込めば、どうしてもロジックが重複しがちになる。
  • 変更を考えると、どこに何が書いてあるか探すのが大変。

ドメインロジックの置き場所
  1. 値オブジェクト
  2. コレクションオブジェクト
  3. 区分オブジェクト

値オブジェクト
  • 値オブジェクトは「1つ」のオブジェクト。

コレクションオブジェクト
  • Listでデータを持って、操作を全部隠す。

区分オブジェクト
  • これだけでもJavaを使う価値がある。
  • 区分オブジェクトのEnumに振る舞いを持たせちゃう。

ドメインロジックのモジュール化
  • トランザクションスクリプトのモジュール分割は、部品化の切り口が不明確になりがち
  • 例えば、受注登録の中のロジックをどう切り分けるかが難しい

構造化:記述レベルの階層化
  • 記述レベルをレイヤーで構造化する。
  • 「ドメイン固有API」を3層の間に入れる。ここを相当考える。
  • JavaコアAPIだけでも行けること多いが、1つ上にドメイン固有APIの層を入れる。
  • アプリ動かすだけならドメイン固有APIの層は明らかにオーバーヘッドだが、この層を入れることによりドメインを扱いやすくなる。

ドメインロジックの自己文書化
  • ドメインロジックの文書化はソースコードでやる。
  • ドメインオブジェクトを参照する3層にもドメインの型が入り込んでくる。
  • これにより他の層のクラスも、ドメインロジックとどう関係してるか語られるようになる。
  • これが変更容易性に直結する
  • 業務マニュアルとか利用者ガイドはすごく重要。必ず作る。保守マニュアルになる。
  • ドメイン側の知識として非常に重要。可能なら開発と平行で作って欲しい。

ドメインを隔離する
  • Springのアノテーション(@Controller、@Service、@Repository)を付けたところにはドメインロジックを入れない。
  • ドメインモデルにはSpringのアノテーションは入れない。
  • 自然にこうなるはず。
  • ドメインモデル以外は、データの入出力。
  • 「データの入出力」と「ドメインモデル」と、関心事が大きく2つ分かれる
  • 関心事が反対側に埋め込まれないことが、ドメインロジックに集中するということ。

プレゼンテーション層とドメインオブジェクト
  • テンプレートにドメインオブジェクトをマッピングする。
  • DTOとかFormオブジェクトを別に設けることは原則していない。
  • プレゼンテーション層にちょっとしたif文とかも書かない。可能な限り書かない。
  • そこまで徹底することで、ドメインオブジェクトにロジックをどんどん入れていく。
  • 変更があったときに、どっちが変更の範囲を閉じ込めやすいか、という観点でドメインオブジェクトに徹底的に抜く
  • Beanスタイルのバインディングは使わない。
  • Thymeleafにドメインオブジェクトをそのまま渡して参照させる。
  • ビューにもドメインを語らせたい。
  • (PRGパターン、という用語が出てきたのでググってみた: TERASOLUNA:PRG(Post-Redirect-Get)パターンについて

Direct Field Access
  • gette/setter全く関係なく直接フィールドを読む。
  • getter/setterをなくすことで、ドメインロジックにすごく集中できる。これはやってみないとわからない。
  • @haljik さんが #kanjava でこの件について相当いい資料をあげている。



アプリケーション層とドメインオブジェクト
  • 記録/参照はリポジトリパターンを使う。データベースの都合をドメインオブジェクトに持ち込まない。
  • プレゼンテーション層とデータソース層の間のやりとりはアプリケーション層が仲介する。
  • 業務ロジックはドメイン層が担う。
  • サービスクラスに@Validatedを付けておくと、バリデーションロジックが賭けちゃう。「契約による設計」
  • Bean Validationを使えると、そうとう細かいところまでチェックできる。
  • リポジトリを@AutowiredでDIする。
  • データソース層がドメイン層に依存するようになる。
  • ドメイン層にsave()とかregister()を持たせるのか、持たせないのかは議論の余地がある。

データソース層とドメインオブジェクト
  • オブジェクトとテーブルはまったく別という扱い。
  • 異なる世界は手作業で明示的にマッピングする。自動マッピングさせない。そのほうが変更に強い。
  • データ保存の概念と業務の分割の概念は必ずしも一致しない。なので手作業で明示的にマッピングする。
  • テーブルは徹底的に正規化する。テーブルには参照制約とか一意性制約とかは入れまくる。
  • <resultMap>のtype属性にドメインオブジェクトを指定し、明示的にマッピングする。
  • SQLがどのドメインに関心があるか、自己文書化させる。


トークセッション「ドメインロジックの実装方法の選択」

モデレータはJSUG会長の長谷川さん。
トークは増田さん、Grailsの綿引さん、TERASOLUNAの池谷さんの3名でした。

Q: DDDをやりたいけど、どうしてもトランザクションスクリプトになってしまう・・・どうすれば?


どうしてもトランザクションスクリプトになってしまう原因は、トランザクションスクリプトに実績があるから。
なのでDDDは浸透してない。しかもアジャイルじゃない。どうすれば?
---

増田さん:
  • 変える気ありますか?
  • トランザクションスクリプトの仕事は受けないくらい気概で行ってる。

綿引さん:
  • DDDの案件で増田さんと一緒に仕事をしていたが、増田さんがリードしないと無理だな、と感じた。
  • まず変わりたい、という時に、リードする人いないと難しいと思う。


Q: リードする人がいないとDDDできないなら、1000人規模のプロジェクトではDDDできないのでは?

池谷さん:
  • 数百人にDDDの本を読ませてできるようにするのに、1ヶ月とか掛かってしまう。
  • なのでトランザクションスクリプトに落ち着くのが現実。
  • 難しい点として、共通化を図ると、それがクリティカルパスになるところが出る。
  • 共通化して開発したいところだが、共通化でネックになることがある。

増田さん
  • 経験者を作るのは相当ハードル高い。
  • でも、トップレベルのエンジニアを作らなくても、1ヶ月DDDを教育することによるメリットは相当ある。
  • 消費税計算とかだけドメインオブジェクトを作るとか、段階的にDDDにするのはけっこう出来ると思う。
  • if文の巣になってるとこを見つけてそこから直していくとか。
  • ヤル気があればできるところってけっこうある。
  • 200人規模ならDDDをやる、って責任はとれないけど、10人くらいなら責任もてると思う。

Q: オブジェクトを共通部品化すると配る必要があるが、大規模プロジェクトだと大変・・・・どうすれば?


増田さん:
  • ドメインは最初から全部は分からないので、最初に全部を部品化するの無理がある。

Q: ウォーターフォールでDDDは無理か?


増田さん:
  • 資料でも、あえて「アジャイル」とうい言葉は使っていない。
  • ウォーターフォールでも行けると思っているが、伝言ゲームはダメ。
  • ウォーターフォールでフェーズがあっても、同じ人間が最後までやるならDDDできると思う。
  • NTTデータさんがすこしDDDに舵を切るだけでも、世界はだいぶ変わる。

池谷さん:
  • DDD本を全部やるのではなく、できるところかやるなら行けると思った。

増田さん:
  • 現場のリーダーの裁量の範囲くらいで、できる範囲からやっていってほしい。

Q: やったことない分野でドメインオブジェクトをどう抜きだせばよいか?

増田さん:
  • その業界のオンラインヘルプ見たりとか、あとは書籍とかから抜く。会計なら、初心者向けの会計本とか。
  • 最初はぜんぜんわかんないけど、目次とかから拾っていく。
  • 最初はぜんぜんわかんないけど、まず触れることが大事。
  • さすがにイテレーションのday-1には全部できないけど、1イテレーションの最後にはできてないとダメ。

Q: 言葉の持ち主は誰?

増田さん:
  • 持ち主はエンジニア。業務用語はお客さんが持ち主。
  • 業務用語集とかを作ってお客さんに渡したりはしていない。
  • メンテをかけるのはエンジニアなんだから、エンジニアがメンテしてドメインにマッピングする。

Q: 日本語だと、業務用語とプログラム変数名に差異が出てしまう。

綿引さん:
  • 日本語を英語にすると、変数名がめちゃくちゃ長くなってしまう。
  • エリック・エヴァンスににどうすればいいか聞いてみたら、「なんで日本語で書かないんだ?」と言われた。
  • 変数名を漢字で書くと、複数形とかが表現できない。あと、メソッドとフィールドが区別できなくなったりする。

増田さん:
  • enumの区分名は日本語にしている。
  • プロダクトコードで名称を日本語で書くのは一度やったことがあるけど、違和感があった。

池谷さん:
  • 英語の変数名から母音を抜いて、子音だけで変数名を作るとかある。

Q: DDDをやる上で何かコツはあるか?

増田さん:
  • 値オブジェクトがコツ。
  • オーバーヘッドでめんどくさいなぁ、と最初は思うけど、やってみると良さを実感する。
  • DBってカラムたくさんあるけど、だいたいすべて同じ型だったりする。
  • なので、値オブジェクトを組み合わせることできたりする。

Q: ORマッパーは、MyBatis以外でもDDDできるか?

JPAでも出来ると思っている。

Q: 実行順序性の制御はどうすれば?

増田さん:
オブジェクトが独立して組み合わせてできないかな、と思ってる。
順番に処理することを無くしたい。ばらばらに呼び出しても、辻褄が合うようにしたい。でも難しい。
順序依存性があるときは、アプリケーション層に制御を持ち込んでいる。ドメイン層には持ち込んでいない。


感想

DDDって抽象的な議論になりがちだけど、こーゆうコードありきで説明いただけると大変助かります。
Springを使ってる身としては、ピンポイントで参考になりました。

増田さんの「ドメインを隔離する」のスライド、4層を縦に並べず、ドメインモデルを3層から分離してその横に書いてますよね。
ドメインモデルが3層から分離され、3層から呼び出されるような図になってます。
この表現の仕方はとても良いと思いました。

というのも、DDD本の4章でレイヤー化アーキテクチャの図が出てきますが、4層が縦に並んだ図になっていて、ドメイン層が分離されている、というイメージが沸かないんですよね・・・
説明の表も縦に4層並んでるし。最初DDD本読んだ時、4層の関係が掴めずにモヤモヤしたもんでした。


あと、会場提供のPivotalさん、懇親会でピザやビールを無料で振る舞ってくださるのも凄いなぁと。
おいしく戴きました。感謝!

あと、こちらもよかったらどぞー



関係者の皆様、ありがとーございました。
次のページ

FC2Ad