Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ドメインオブジェクトとユースケースの関係について
Search
kawakawa
December 04, 2018
Technology
10
3.7k
ドメインオブジェクトとユースケースの関係について
DDDを通じて疑問に思ったことを、ドメインオブジェクトとユースケースの関係を通じて考えてみたことをまとめてみました。
kawakawa
December 04, 2018
Tweet
Share
More Decks by kawakawa
See All by kawakawa
モデル図の難しさについて
kawakawa
1
250
キーワードで振り返る暗黙知の次元
kawakawa
0
400
オブジェクト指向の「語る」と「示す」
kawakawa
9
22k
心理的安全性ゲームをやってみよう
kawakawa
2
2.8k
Other Decks in Technology
See All in Technology
Commitment vs Harrisonism - Keynote for Scrum Niseko 2024
miholovesq
6
960
プロダクトエンジニアが活躍する環境を作りたくて 事業責任者になった話 ~プロダクトエンジニアの行き着く先~
gimupop
1
440
コンテンツを支える 若手ゲームクリエイターの アートディレクションの事例紹介 / cagamefi-game
cyberagentdevelopers
PRO
1
110
AWS CDKでデータリストアの運用、どのように設計する?~Aurora・EFSの実践事例を紹介~/aws-cdk-data-restore-aurora-efs
mhrtech
4
610
グローバル展開を見据えたサービスにおける機械翻訳プラクティス / dp-ai-translating
cyberagentdevelopers
PRO
1
150
端末が簡単にリモートから操作されるデモを通じて ソフトウェアサプライチェーン攻撃対策の重要性を理解しよう
kitaji0306
0
170
物価高なラスベガスでの過ごし方
zakky
0
320
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
49k
GitHub Universe: Evaluating RAG apps in GitHub Actions
pamelafox
0
170
Amazon FSx for NetApp ONTAPを利用するにあたっての要件整理と設計のポイント
non97
1
160
小規模に始めるデータメッシュとデータガバナンスの実践
kimujun
3
550
クライアントサイドでよく使われる Debounce処理 をサーバサイドで3回実装した話
yoshiori
1
140
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
13
1.9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Faster Mobile Websites
deanohume
304
30k
Making Projects Easy
brettharned
115
5.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
Measuring & Analyzing Core Web Vitals
bluesmoon
1
39
Automating Front-end Workflow
addyosmani
1365
200k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Transcript
ドメインオブジェクトと ユースケースの関係について ドメイン駆動設計 #1 Advent Calendar 2018 https://qiita.com/advent-calendar/2018/ddd
はじめに 業務フローから落とし込まれたユースケースは存在す るのですが、そこから「ドメインオブジェクト」を組み立て ても、ちょっとした変更でやり直す日々が続き、上手い ドメインの見つけ方はどうやればいいのか、悩んでい ました。 ある日、DCI(Data, context and interaction)というパラ
ダイムを知り、その考え方を拝借することで、私なりの ドメイン理解への道筋が見えてきました。 今回はユースケースとドメインの関係について、 自分が悩んできた疑問点を中心に紹介したいと思いま す。 2
自己紹介 • かわべたくや • Twitter:@kawakawa • 大阪で働くプログラマー • 業務系Windowsアプリ開発が多め •
DDD(DonDon-Debuni)猛進中 • 進捗が3倍遅い事から 「赤いイナズマ(線)のC#er」の 二つ名を拝命 3 (やばい、痩せないと)
疑問1 ユースケースからドメインを どうやって見つけたらいいのだろう? 4
ドメインの見つけ方は? 下の絵におけるドメインオブジェクトは 何になりますか? 5
ドメインの見つけ方は? 種別は「リンゴ」、色は「赤」、 振る舞いは・・・まだ判らないですね。 6
ドメインの見つけ方は? 木から落ちるリンゴ。 振る舞いは・・・「落ちる」でしょうか。 7
ドメインの見つけ方は? 次の場合はどうでしょうか。 女の子が落ちるリンゴを見ています。 8
ドメインの見つけ方は? 今度は、 ニュートンが落ちるリンゴを見ています。 9
ドメインの見つけ方は? 2つを並べてみます。 「女の子が落ちるリンゴを見ています。」 「ニュートンが落ちるリンゴを見ています。」 10
ドメインの見つけ方は? 黄色の個所が異なることが判ります。 「女の子が落ちるリンゴを見ています。」 「ニュートンが落ちるリンゴを見ています。」 女の子・ニュートンの違いを見て思うことありま すか? 11
ドメインの見つけ方は? 女の子・ニュートンを「観察者」と表現すると 1つのユースケースに出来そうです。 「観察者が落ちるリンゴを見ています。」 では、なぜ「観察者」として、まとめることが出来 ると理解できたのでしょうか? 12
ドメインの見つけ方は? 女の子とニュートン、個々でみると性別も異なり、 抽象度も異なります。 (片方は名詞で、片方は人物名) しかし、「観察者」として1つにできると、 なぜか理解できました。 もう少し深堀してみたいと思います。 13
ドメインの見つけ方は? 次のケースです。 女の子が「大きな」「リンゴ」を「お金」で 買う場面です。 14
ドメインの見つけ方は? 次は、 コックが「高品質な」「リンゴ」を「カード」で 買う場面です。 15
ドメインの見つけ方は? 同じように並べてみます。 「女の子」が「大きな」「リンゴ」を「お金」で購入 「コック」が「高品質な」「リンゴ」を「カード」で購入 16
ドメインの見つけ方は? 異なる個所を抜き出し、 また1つの単語に変換してみます。 「女の子」が「大きな」「リンゴ」を「お金」で購入 「コック」が「高品質な」「リンゴ」を「カード」で購入 購入者 選択基準 購入手段 17
ドメインの見つけ方は? 文章を整理してみましょう。 「購入者」が 「選択基準」に従って リンゴを 「購入手段」で購入する ここから何が見えてくるのでしょうか? 18
ドメインの見つけ方は? 1つはマークした個所は可変なこと。 「購入者」が 「選択基準」に従って リンゴを 「購入手段」で購入する 19
ドメインの見つけ方は? 逆にマークしてない個所は固定(共通)です 「購入者」が 「選択基準」に従って リンゴを 「購入手段」で購入する 20
ドメインの見つけ方は? どうやら、ユースケースから 「可変」な個所と 「固定(共通)」な個所を 認識することで、ユースケースを まとめるという事が出来たようです。 21
ドメインの見つけ方は? もう一度ユースケースを見てみましょう。 「女の子」が「大きな」「リンゴ」を「お金」で購入 「コック」が「高品質な」「リンゴ」を「カード」で購入 購入者が決まると選択基準・購入手段が決まりま す。つまり依存関係があると言えそうです。 (例:女の子はクレジットカードを使えません) 依存 依存 購入者
選択基準 購入手段 22
ドメインの見つけ方は? 固定(共通)箇所に関しても 「女の子」が「大きな」「リンゴ」を「お金」で購入 「コック」が「高品質な」「リンゴ」を「カード」で購入 「購入者」が「対象」を「購入」というユースケースとしての 関係性(構造)は持っているようです。 依存 依存 購入者 対象
購入行為 23
ドメインの見つけ方は? 可変と固定(共通)は次の関係があると言えそう です。 可変 固定(共通) 依存 or 排他 可変 可変
依存 or 排他 固定(共通) 固定(共通) 依存 or 排他 24
ドメインの見つけ方は? 「可変」と「固定(共通)」の関係性が判ると、 そこから、ユースケースを揺さぶり、より詳しい 関連性が見つかりそうです。 「購入者」が 「選択基準」に従って リンゴを 「購入手段」で購入する 例) ほんとに固定?可変っぽい
例) 色々なパターンありそう 例) 購入以外もありそう 例) 日本限定?/ 将来も通用できるの? 25
ドメインの見つけ方は? ユースケースを通して、「可変」と「固定(共通)」 の関係性を捕える事ができました。 私が難しいと思っていた時代のドメインは、モ ノ・コト個々の繋がりしか考慮しておらず、 関連性を考慮していませんでした。 ユースケースの揺さぶりも無かった為、 変更に弱い「浅いドメイン」しか見ていなかった のが原因のようです。 26
ドメインの見つけ方は? ドメインを捕える事が出来れば、 そこから新しいユースケースを考える事も出来、 システムの汎用性も高まりそうです。 ドメイン ユースケースA ユースケースB 新しい ユースケース 27
ドメインの見つけ方は? DCIは「可変」と「固定(共通)」を 「Data」と「 Interactions 」に分けて、 「Context」でユースケースを表現するという 上手いやり方だと思います。 しかし、ここで次のような疑問が浮かんできまし た。 28
疑問2 「可変」や「固定(共通)」の関連性、 DCIのユースケースなど、それらを成り立たせる 「ルール(制約・制限)」があるのなら、 それこそが「真・ドメイン」と言えるのではないだ ろうか? つまり、ドメインとは「ルール」と言えるのか? 29
ドメイン = ルール? 再度、女の子の購入場面です なぜこのユースケースが成り立つのでしょう か? 30
ドメイン = ルール? このユースケースが成り立つ根本ルールは何 でしょうか? 商法? 市場原理? 八百屋組合? ・・・・いっぱいあり過ぎて、書ききれません。 31
ドメイン = ルール? そもそも なぜ、この店で買うのか? なぜ、女の子は買い物という行為を知っている のか? 女の子がなぜこの店で買うのか? という根本ルールなんて書けません。 うーむ・・・
32
ドメイン = ルール? 視点を変えて、 ルールがしっかり決まっている将棋で 考えてみたいと思います。 33
ドメイン = ルール? 将棋はルールの全てを記することができます。 ・コマの動き ・勝敗の条件 など しかし、それだけで将棋というものを、 表現できるのでしょうか? 34
ドメイン = ルール? ・戦法 ・記譜 ・読み筋 ・勝負所 ・相性 ・体調 ・・・将棋を表現するのに必要なモノは
まだまだありそうです。 どうやら、見えているルール以外にも何か必要 そうです。 35
ドメイン = ルール? 同じようにサッカーもルールが厳密に定められ ています。 しかし、ルールのみではサッカーを表現できま せん。 36
ドメイン = ルール? ドメイン=ルール と言えなくともないようですが、 全てを記すことはできないみたいです。 もし、ルールを記したとしても、そのルール自体 の成立する条件を書く必要が出てきて、 ルールのルールが必要となってしまいます。 37
ドメイン = ルール? ドメイン = ルール は、 間違っていなそうですが、正解というには何か 足りないようです。 そこで、次の疑問が浮かんできます。
38
疑問3 どれだけのユースケースを集めれば、 ドメインを理解したと言えるのだろう? 39
必要なユースケースの数は? ウィトゲンシュタインの「言語ゲーム」に 興味深い話が載っていました。 「まったく「イス」というものを知らないAさんがい ます。「イス」が何なのかを教える為に、手元に あった「イス」を幾つか用意しました。」
必要なユースケースの数は? 「Aさんは、2~4脚「イス」を見て、触って、 座ると「イス」が何なのか理解したよと言いまし た。」 「その後、2人でカフェに行った処、Aさんは自分か ら初めて見る「イス」に座ることができました」
必要なユースケースの数は? Aさんは少ない実例から、イスの法則を見つけ 出したと言えます。 人には少ない事例から、一定の法則を見つけ 出す力があるようです。 そして、難しいのが次の質問です。
必要なユースケースの数は? もし、あなたがAさんだったとしたら、 「イス」と判った理由を説明できますか? 43
必要なユースケースの数は? イスと理解したことを、言葉で説明するのは 難しいと思います。 「イスと理解すること」 と 「イスと理解したことを説明すること」 はどうやら異なるようです。 44
必要なユースケースの数は? 「言語化(形式化)は難しいが、 理解していること」 一般的に「暗黙知」と言われています。 つまり、一定の法則が存在する事は 理解できるが、その法則自体を書きだすのは 難しいと言えます。 45
必要なユースケースの数は? 次の場合はどうでしょう 1、2、3、5、? ?は、何になるでしょうか? 46
必要なユースケースの数は? 次の場合はどうでしょう 1、2、3、5、? ?は、何になるでしょうか? • 1と素数と思った人は、「7」 • 前項の足し算と思った人は、「8」 と考えた人が多いと思います。 47
必要なユースケースの数は? 「7」と「8」 どちらも正解です。 そう思った数が正解です。 48
必要なユースケースの数は? もし、続けた場合 • 1、2、3、5、7、? • 1、2、3、5、8、? それぞれの「?」には何が入りますか? 「11」と「13」 そう思ったのなら、それが正解です。 49
必要なユースケースの数は? 関係者が「••」であると共通認識をもって、 合意できる事が大事なのだと言えそうです。 つまり、関係者間の合意が取れるまでが、 必要なユースケースの数と言えます。 もし異なるユースケースが発生したら、 その時に再度、ドメインの分析を行えば いいのです。 50
疑問4 共通認知する為には何が必要? 51
共通認識に必要な物は? 共通認識は、ユースケースを通じたドメインから 行います。 そのドメインを「言葉」だけで やり取りした場合、どういう事が起きるのか 考えてみたいと思います。 52
共通認識に必要な物は? 2人が、リンゴの色を それぞれ思い浮かべてます。 53
共通認識に必要な物は? 次のセリフは互いに違和感なく成り立ちます 綺麗なリンゴ の色 54
共通認識に必要な物は? 次も成り立ちます リンゴ色の空が ステキ (青空・夕焼け) 55
共通認識に必要な物は? 次も成り立ってしまい、大変なことになります! リンゴ色の時に 信号を渡る 56
共通認識に必要な物は? どうやら、言葉だけでは共通認識に差異が発生 していても、気づけない場合がありそうです。 ドメインの実際の振る舞いも 共通認識形成には大事な要素と言えます。 57
共通認識に必要な物は? ただし、言葉の差異が単純にデメリットとも言え ません。 逆に考えると、振る舞いが確定するまでは、 認識に差異があっても問題無かったと言えます。 つまり、認識を合わせる時まで、 遅延できる(≒実装を遅らせる)という メリットもあります。 58
共通認識に必要な物は? 次に、言葉の適切な抽象度について考えてみ たいと思います。 59
共通認識に必要な物は? 富 資産 家畜 牛 ベッシー 抽象度:高 抽象度:低 S・I・ハヤカワ氏の「牛のベッシー(抽象のはし ご)」という話があります。
ベッシー 60
共通認識に必要な物は? 家族との会話、 「ベッシーにエサをあげる」 友人との会話、 「牛にエサをあげる」 話は通じそうです。 つづけてみます。 61
共通認識に必要な物は? 知り合いに対して 「家畜にエサをあげる」 取引先に対して 「資産にエサをあげる」 ・・あれ? どうやら、ユースケースを通すことで、 適切な抽象度を自然と選択できているようです。 62
共通認識に必要な物は? 次に言葉の問題点として、 言葉は、そのコンテキストをほんの少し変えると、 途端に意味が変わってしまう場合があります。 簡単な例をあげます。 63
共通認識に必要な物は? 「今の時間は?」 この質問に答えられますか? 64
共通認識に必要な物は? 次に 「時間って何?」 この質問に答えられますか? 65
共通認識に必要な物は? 「時間」という単語を、 コンテキストを飛び越えて使ったために 起きた問題です。 同じ単語でもコンテキスト、ユースケースなど間 違えて使用すると途端に意味が通じなくなって しまいます。 66
共通認識に必要な物は? つまり、 • ユースケースを文章にして意味が通じる • ユースケースの実際の振る舞いを確認する これらの作業が共通認識を行うために、 必要な事と言えます。 67
まとめ まとめ 68
まとめ DDDを進めるうえで出てきた疑問を ユースケースとドメインの関係を通じて、 こうなのでは?という自分なりの回答を記載さ せて頂きました。 69
まとめ ドメインとユースケースは相互関係です。 ドメインが変わればユースケースも変わり、 ユースケースが変われば、ドメインも変わります。 70
まとめ 大事なのは、 • 会話によるドメイン構造のフィードバックループ • ユースケースによるドメイン振る舞いの フィードバックループ この繰り返しだと思います。 「ぐるぐるDDD」ですね。 71
まとめ 自分はまだまだ試行錯誤の最中です。 ご意見・ご感想・アドバイス・・・ ご連絡頂ければ嬉しいです。 https://twitter.com/kawakawa よろしくお願いします♪ 72