ひとの想いをのせたドメインモデル

1. ひとの想いをのせた
ドメインモデル
発表者名
(株)チェンジビジョン 工藤 ゆみ

2. 議題
ドメインモデリング
について
① モデリングの恩恵
② 過信
③ ひとの想いをのせたドメインモデル
④ 活動PR
2022/9/13 ひとの想いをのせたドメインモデル 2

3. 概要
ドメインモデルを通して、
曖昧だった言葉の定義が明確になるだけでなく、
色々試行錯誤して、
【ひとの想いをのせたモデル】
を作成するアートの素晴らしさを伝えたい。
※ドメインモデル・・・
DB、FWなどの制約をかける前の、業務を表す部分だけ抽出したパーツの同士の関係
性を表したもの、ていう提で使います。
3

4. 自己紹介
現職 (株)チェンジビジョン モデリング事業部所属
2021年秋からIT業界へ。そろそろ2年目。
IT業界入る前は、
予備校講師や飲食店、接客など。
趣味 お茶会という名の勉強会と 編曲(Ba&Drトラック)
業界入る前はプログラミングとか苦手意識。
今ではモデリングが変態的に好きな奴。
4

5. ①モデリングの恩恵

6. プログラミング開始当初は、、、
6
プログラミングを学び始めた当初
⇒手続き型のコードすらまともに書けない。悲
オブジェクト指向の書籍とか読んでも、文章ばかりで「？？？」となる。
トップダウン式の学習が向いた性格なので、
具体的なコードよりも図で概念や背景から説明の方が嬉しい。
⇒ そんなものはなかなかなかった(-_-;)。

7. 転機～モデリングとの出会い～
7
職業訓練校在学中に入ったJavaのコミュニティにてモデリングに出会う。
⇒
モデリングの資格本の問題を改造して、
コアなドメインを１から考えたりするなどの練習を重ねた。
⇒
そのうえで設計原則などの指標を今一度学習した結果、
大幅にカプセル化などのモデリング力が上がりました。
ワァ～～イ！

8. ②過信

9. 私は最強！(￣▽￣)
9
自分を過信してしまい、
モデリングこそすべてだ！！
「私は最強！」と図に乗る。
⇒ 短期間で鼻をへし折られる、
ダメ出しをされる
など様々な痛い目に遭遇。
ニヤリ

10. モデリングはあくまで手段
10
いつからかドメインモデリングの作業が
目的になってしまってた。Ω＼ζ°)ﾁｰﾝ
もともとの要求がそもそも使い手にとって
価値のあるものなのか検討もせず、、、、。
反省の先にたどり着いたのは⇒
様々な別れもあり反省

11. ③ひとの想いをのせた
ドメインモデル

12. 想いをのせたモデルって？(概要)
ただモデルの構成関係表しただけの図は🙅NO
①
見る側の視点でもっとも関心を抱いてほしい部分だけの構成。
それ以外はそぎ落としてOK！
②
「こうあるはずだ」て常識を取っ払って、
ユーザー視点での「便利だな」って思う要求を実現できるモデル。
ステークホルダの中で優先させたい要求が投影できてるか？てこと。
12

13. 実体験(宿泊予約システム)
※前提として、複数の全国の宿泊施設を予約できるものでなく、１つの宿泊施設の予約管理システム。
このシステムを使う顧客は「宿泊予約をする」というユースケースを使う。
この時、予約ってものに関しての願望や認識って？？
・１回の予約で１部屋しか予約できないもの
・１回の予約で複数部屋予約できるもの
みんなが前提で【当たり前】て考えている 視点 がそもそもずれているのが当たり前。
予約ってものに関する願望や認識が、今のままだとブレブレ。
13

14. ～モデル図で比較確認～
14

15. 15
上図の理由から、ユースケース「宿泊予約をする」ていうのは、
顧客が１度の予約で1部屋以上の客室を予約可能な状態を実現すること、
て定義できるので、２通りのモデルの右側が妥当なモデルといえる。

16. ユーザー視点で
「こんなだったら嬉しいのにな」
という想いの分析なしで作ったモデルに
価値はなし。
16
別れや出会いを通して
原点回帰したわたしの導いた結論

17. ④活動PR

18. 現在主催してる勉強会
• ユースケース駆動でのドメインモデリング祭り
• エヴァンス本読書会
• ユースケース駆動開発実践ガイド(現在企画中)
connpassで第1回目まだ募集中
18

19. 今後予定してる勉強会
• JUnit実践入門
• マイクロサービスパターン
• アナリシスパターン
19

20. まとめ
ドメインモデルとは、
ただのカプセル化された集合の構成図ではない。
ステークホルダにとって「便利だな」「こうあってほしいな」
という強い願い、想いが表現されていてこそ価値がある。
また、それをつくっていく過程に沢山の感動体験がある！
と実体験を通して感じました。
2022/9/13 ひとの想いをのせたドメインモデル 20

21. 単一責務は分析の段階から(補足 我流込み)
関係性の密な分離できない属性をまとめた結果、
その属性に唯一の名前がつけられる状態。
たった１つでも無関係な属性が混ざってる瞬間、複数の名前が付けられ得る。←複数責務
注文管理システムとかで
注文日時、合計金額、発送予定日 とかまでで「注文」ていう事象の名前つけたい。
でもここに 顧客氏名 とかって混ざってきたら、人としての責務と注文て２つの責務。
(多分だけどDB設計で注文テーブルに顧客IDとかって属性があることにひきづられてるのかな？？)
○○(クラス名)の△△(属性)て読み上げてみる。
注文の 氏名 て明らかにおかしい。
属性の集合が責務を決める、GRASPの情報エキスパートと高凝集を是非見てください。
2022/9/13 ひとの想いをのせたドメインモデル 21

22. ありがとうござ
いました！
2022/9/13 ひとの想いをのせたドメインモデル 22
発表者名 工藤 ゆみ
Web サイト
https://qiita.com/Kudo_panda
Qiitaアカウント名 せやかて 駆動