Dojo夏休み企画：挫折しないドメイン駆動設計（DDD） - connpass を聴講したのでそのノート。
ドメイン駆動設計（DDD）とは
- DDDの関心の高まり
- ドメインって何
- ドメインに興味を持とう
- ドメインを分析する
DDDをこれから勉強したい方に「DDDに興味を持って、良いね！と思うこと」が今回のゴール
DDD
- エリック・エヴァンス氏が提唱した
- ソフトウェアの設計・開発手法
- 顧客も開発者も、システムに関わる人皆が共通の言葉を持って、同じ認識を持ってシステムを作り上げるのがDDD
共通の言葉とは
単なる言い回し？
ではなく、顧客と開発者が歩み寄るイメージのもの
実際の業務をきちんと理解しないで作ったら、リリースしてもあまり使われなかった...
業務変更のためソフトウェアを修正することになっても、どこを直せばよいかすぐわからない...
これらの事態を防ぐため
業務の本質を理解して、価値あるソフトウェアを作ることを目指す。
DX、マイクロサービス、アジャイル開発、を背景に注目されていて、頻繁なコード変更にも耐えられるような、変化に強いシステムを目指すもの。
ドメインってなに？
「システム化する際に対象となる業務」
ドメイン駆動とは、業務を理解するところから始めるということ。
例えば、映画館のチケット購入システム
- 上映映画に対する座席数
- 料金
- その映画館の「業務上の決まりごと」
- 「業務上の決まりごと」を知らないとどんなシステムを作ればよいかわからないので、知る必要がある。
- 「業務上の決まりごと」を正しく理解するために、ドメインモデルを作る。
- ドメインモデルとは、「業務上の決まりごと」を整理したもので、ソフトウェア開発のインプットとなるもの。
- ドメイン→ドメインモデル→ソフトウェア
- ドメインモデルを見れば、業務担当者も開発者も共通理解ができる。
- ドメインモデルはどうやってつくるの？
- 業務の仕組みやルールに詳しい人の話（= ドメインエキスパート）を聞くこと。
- 映画館の例なら
- 映画館の館長
- チケット売りのスタッフ
- 映画館の常連さん
ドメインモデルを作ろう
例題: 映画チケット購入システム
- ドメインエキスパートの話に耳を傾ける
- 単語をピックアップする
- 単語を線で結んで関連付ける
「座席予約表を見て空いている席を確認します」
「どの座席予約表を見るかは、映画の上映タイトル、日時で決まります」
「座席番号を選択して、席を確保します」
「座席を確保後、料金を計算します」
「料金の支払いが完了したらチケットを発行します」
「料金の計算は購入者の性別、年齢、曜日、特別割引日などにより決まります」
目的語に特に注意。
参照するもの、利用するもの、インプットするものなどという観点から関連付ける。
- 座席予約表
- 上映タイトル
- 日時
- 座席番号
- 料金
- チケット
- 購入者の性別や年令
- 料金の計算
- ドメインエキスパート:「レイトショーなら一律1000円、60代以上夫婦割、レディースデー等」
- 開発者:「基本料金から割引をして最終的な料金が決まるのですね」
こうして共通言語を作っていくことを、ユビキタス言語という
ソフトウェアに必要な概念が網羅されているか？
ドメインを定義
業務をさらにグルーピングしてドメインを定義し、ビジネス価値を提供するために特に重要なドメインをコアドメインとして定義する。
コアドメインに注力してDDDをすすめる。
- 座席予約ドメイン
- 料金支払いドメイン
等など
ドメイン分析例題「美容院の予約システム」
ドメインエキスパートの声
「カット、カラー、パーマなど、どのメニューにするか確認します。」
「担当者を確認します。」
「予約表を確認して、空いている日時をご案内します。」
「お客様の年齢、担当者、メニューによって料金が決まります。」
「当日の3日前まで予約の変更、キャンセルを受け付けます。」
以上を題材に考えてみるのが練習。
追加でドメインエキスパートに質問したいことはあるか？等も、考えてみるのがポイント
参考資料
ドメイン駆動設計 基本を理解する
draw.io等がダイアグラムを描くのに良い
DDDは業務が変更されたら随時更新していくもの
ユビキタス言語の用語集を作って満足してしまったりするのがアンチパターン
システムの複雑度合い、不確定度合いなど、使い所は見極める必要がある。
ということで、たのしみながらDDDをすすめてみよう～ という感想。
ドメイン駆動開発を浸透させるための新しい取り組み - SO Technologies 開発者ブログ の資料も読みたい。
以上メモ仕立てですが、参考になればさいわいです。