IBM Dojo 挫折しないドメイン駆動設計 20210825pm

1
© 2021 IBM Corporation
挫折しないドメイン駆動設計（DDD）
⽇本アイ･ビー･エム株式会社
テクノロジー事業本部
カスタマー・サクセス・マネージャー
松⼭由莉⼦
Dojo夏休み企画

View Slide

2
アジェンダ
n DDD超概要
- DDDとは
- DDDの関⼼の⾼まり
n ドメインって何︖
- ドメインに興味を持とう
- ドメインを分析する
n ドメインモデルを作ってみよう
n DDDで挫折しそうになった話
n いろいろな設計開発の⼿法
n まとめ

View Slide

3
• 対象者
• ドメイン駆動設計をこれから勉強したい⽅、ドメイン駆動設計ってなに︖という⽅向け
• ゴール
• ドメイン駆動設計に興味を持って、良いね︕と思っていただくこと
はじめに

View Slide

4
DDD超概要

View Slide

5
ドメイン駆動設計は英語で「Domain Driven Design」
ドメイン駆動設計（DDD）とは、2003年にエリック・エヴァンス⽒が『Domain-driven design』という
書籍にて提唱したソフトウェアの設計・開発⼿法です。
DDDは、顧客（業務担当者）と開発者が業務を戦略的に理解し、共通の⾔葉を使いながらシステムを発展させる
⼿法です。
DDD超概要
顧客も開発者も、システムに関わる人みんなが共通の言葉を持って、
同じ認識を持ってシステムを作り上げるのがDDD
https://www.amazon.co.jp/Domain-Driven-
Design-Tackling-Complexity-
Software/dp/0321125215
https://www.amazon.co.jp/-
/en/%E3%82%A8%E3%83%AA%E3%83%8
3%E3%82%AF%E3%83%BB%E3%82%A8
%E3%83%B4%E3%82%A1%E3%83%B3%E
3%82%B9/dp/4798121967/ref=pd_lpo_1?pd_
rd_i=4798121967&psc=1

View Slide

6
ドメイン駆動設計（DDD）では
これらの事態を防ぐため、
業務の本質を理解して、価値あるソフトウェアを作ることを⽬指す。
実際の業務をきちんと理解しないで作ったら、リリースしてもあんまり使われなかった、、、
業務変更のためソフトウェアを修正することになっても、どこを直せば良いかすぐわからない、、

View Slide

7
DDDが注⽬される背景は︖
DDDへの関⼼の⾼まり
頻繁なコード変更にも耐えられるような
変化に強いシステムが求められているなかで、DDDへの関心が高まっている。
デジタルトランス
フォーメーション
（DX）
マイクロサービスアジャイル開発
DDD

View Slide

8
ドメインって何︖

View Slide

9
• ドメイン駆動設計での”ドメイン”とは︖
• システム化する際に対象となる業務。
• “ドメイン駆動”とは?
• 業務を理解するところ始めるということ。
• 例えば、、、映画館のチケット購⼊システムを作りたいとき。
• 上映映画に対する座席数の決まり
• 料⾦の決まり
などなど、、
その映画館の業務上の決まり事がある。
業務の決まり事を知らないとどんなシステム作れば良いかわからないので、知る必要がある。
ドメインってなに︖その１
ドメインに関心を持つことが大事。

View Slide

10
業務担当者も開発者も、システムに関わる⼈みんなが業務の決まり事を正しく理解するために、ドメインモデルを作る。
ドメインモデルとは、業務の決まり事を整理したもので、ソフトウェア開発のインプットとなるもの。
ざっくりいうと、、
共通認識を持ってドメインモデルを作って、＝戦略的設計今⽇はここにフォーカス︕
それをそのままコードに落として実装する＝戦術的設計
ドメインってなに︖その２
業務の課題や問題が潜んでいる部分
ドメイン
解決しよう！
ソフトウェア
ドメインモデル
ドメインモデルを見れば、業務担当者も開発者も共通理解ができる！

View Slide

11
まず重要なのは、業務の仕組みやルールに詳しい⼈の話（＝ドメインエキスパート）を聞くこと。
映画館の館⻑、チケット売りのスタッフ、もしかしたら映画館の常連さんかも、、
（⼀般的には、システム発注者、その業務を⾏う社員、担当営業、、、）
ドメインモデルどうやってつくるの︖
業務の課題や問題が潜んでいる部分
ドメイン
解決しよう！
ソフトウェア
ドメインモデル
業務の決まり事を整理したもの
業務に詳しい人から聞いた話を分析して整理する（ドメイン分析）
＝ドメインモデルを作る
ドメイン分析

View Slide

12
ドメインモデルを作ってみよう

View Slide

13
ドメインモデルを作ろう。
ドメインモデル例題︓映画チケット購⼊システム

View Slide

14
ドメインを分析しよう
1
２
3
ドメインエキスパートの話に⽿を傾けます。
• ソフトウェアに落とし込む際に重要な概念があるはず。注意深く聞きます。
• ドメインエキスパートの話の中から、単語をピックアップします。
• 「”〇〇”をもとに〜」、「”〇〇”を参照して〜」、などの⽬的語に特に注意します。
• 単語を線で結んで関連付けます。
• 「参照する」・「利⽤する」・「情報のインプットとなる」という観点から関連づけます。

View Slide

15
ドメイン分析例題︓映画チケット購⼊システム
step1
Q.映画のチケット販売はどのような流れで⾏いますか︖
A.ドメインエキスパートの声
「座席予約表を⾒て空いてる席を確認します」
「どの座席予約表を⾒るかは、映画の上映タイトル、⽇時で決まります」
「座席番号を選択して席を確保します」
「座席を確保後、料⾦を計算します」
「料⾦の⽀払いが完了したらチケットを発⾏します」
「料⾦の計算は購⼊者の性別、年齢、曜⽇、特別割引⽇などによります」

View Slide

16
step２
「料⾦の計算は購⼊者の性別や年齢、上映⽇時などによります」

View Slide

17
step2
チケット
上映タイトル
上映日時
座席番号
料金
座席予約表
購入者属性
（性別・年齢）

View Slide

18
step3
チケット
上映タイトル上映日時
座席番号
料金
座席予約表
購入者属性
単語を線で結んで関連付けます。

View Slide

19
1
２
3
• 単語を線で結んで関連付けます。
• 「参照する」・「利⽤する」・「情報のインプットとなる」という観点から関連づけま
す。
４ • ソフトウェアに必要な概念が網羅されているか︖

View Slide

20
step4
Q. 料⾦の計算はどうやっている︖
「レイトショーなら⼀律1000円、60代以上夫婦割やレディースデーなど、
必要に応じて割引します。」
チケット
座席番号
料金
座席予約表
購入者属性
• ソフトウェアに必要な概念が網羅されているか︖

View Slide

21
Q. 料⾦の計算はどうやっている︖
「レイトショーなら⼀律1000円、60代以上夫婦割やレディースデーなど、
必要に応じて割引します。」
Q.「基本料⾦から割引をして最終的な料⾦が決まるのですね。」
共通言語を作っていく
＝ユビキタス言語
step4
チケット
座席番号
最終料金
座席予約表
購入者属性
基本料金
• ソフトウェアに必要な概念が網羅されているか︖

View Slide

22
1
２
3
ドメインエキスパートの話の中から、単語をピックアップします。
単語を線で結んで関連付けます。
４ソフトウェアに必要な概念が網羅されているか︖
ドメインを定義します。
業務をさらにグルーピングしてドメインを定義し、ビジネス価値を提供するために特に重要なドメインを
コアドメインとして定義します。
5

View Slide

23
チケット
座席番号
最終料金
座席予約表
購入者属性
基本料金
step5 ドメインを定義します。
業務をさらにグルーピングしてドメインを定義し、ビジネス価値を提供するために特に重要なドメインを
コアドメインとして定義します。
料⾦⽀払いドメイン
座席予約ドメイン
サブドメイン
コアドメイン
＝システム化す
る価値が高い
＝ビジネス利益
につながる
コアドメインに注力してDDDを進める。

View Slide

24
ドメインモデルを作ってみよう

View Slide

25
Q.美容院の来店予約はどのような流れで⾏いますか︖
「カット、カラー、パーマなど、どのメニューにするか確認します。」
「担当者を確認します。」
「予約表を確認して、空いている⽇時をご案内します。」
「お客様の年齢、担当者、メニューによって料⾦が決まります。」
「当⽇の3⽇前まで予約の変更、キャンセルを受け付けます。」
ドメイン分析例題︓ 「美容院の予約システム」

View Slide

26
• ドメインモデル作成についてのポイント
• ドメインモデルを作るための決まった⽅法やツールはない。
• どの⽅法やツールを採⽤しても、ドメインエキスパートから得た知識を表現していくことは変わらない。
• どんどん更新していくもの、⼀度やって終わりではない。
• ドメインモデルを作るためのさまざまな⽅法
• ユースケース⼀覧やユースケース図を作って、業務を整理する。
• 特に新規事業の場合、初めにユースケース（誰がいつ何をやるか）を書き出しておくと良い。
• SCNを作って、ビジネス戦略を知る。
• ※SCN (Strategic Capability Network）は、1998年にIBMワトソン研究所が開発した戦略策定⼿法で、プロジェクトの提供価値（⽬
的、狙い）が創出されるロジックを可視化する。
ドメインモデル作成のポイント
座席を選
択する
料金を計
算する
ユースケース図の例
SCN(⾦融業での分析・検討例)
https://www.ibm.com/blogs/think/jp-
ja/provision-microservice-build/

View Slide

27
DDDで挫折しそうになった話

View Slide

28
その1
ドメインエキスパートがいない状態でスタートしてしまった︕︕
後からドメインエキスパートにヒアリングする機会があり、そこでドメインモデルを直したが、最初からヒアリングした⽅が
効率的だった。
Point
ドメイン分析は、ドメインエキスパートの話を聞くことから始まる。
ドメインエキスパートを探すのにも時間がかかる。早めにオファーしておくこと。

View Slide

29
その2
ドメイン駆動設計（戦略的設計）に予定の２倍の時間がかかり、
開発時間がギリギリに︕
ドメインモデルの正確さを求めすぎて時間をかけすぎた。
ドメインエキスパートがいないと想像するしかないので悩む時間が多かった。
開発とフィードバックを繰り返してそのサイクルをなるべく短く進めるのが⼤事。
Point
事前に制限時間を決めて取り組むのが良い。
反復的に実施するものであり、⼀度実施して完了ではない。
業務が変更されたタイミング、ドメインについての理解が深まったタイミングで随時更新していくもの。

View Slide

30
その３
ユビキタス⾔語の⽤語集作って満⾜してしまった︕︕
業務の⽤語を⼀覧化したものを作成したが、結局、⽤語集を使うタイミングがなかった。
チーム全体で共通⾔語を作り上げるためのユビキタス⾔語なのに、ドメインエキスパートからヒアリングして⼀覧にしただけ
では、単に業務担当部⾨の認識ずれを整理したものでしかなかった。
Point
ユビキタス⾔語は、ドメインエキスパートと開発者含め、チーム全体で育てていくもの。
認識を合わせることは⼤事だが、ドメインモデルがきちんと表現できれば、無理に⽤語集を作る必要はない。

View Slide

31
DDD分析にあたっての⼼構え
n ドメインエキスパートと開発者が同じ⼟俵の上で作業することで、業務・技術双⽅の視点を踏まえたソフト
ウェアを作ることができる。よって、DDDには、ドメインエキスパートの存在が不可⽋。ドメインエキスパートは、業務の流れに
ついてよくわかっている⼈であれば誰もがドメインエキスパート。
n DDDは、反復的に実施するものであり、⼀度実施して完了ではない。業務が変更されたタイミング、ドメインについて
の理解が深まったタイミングで随時更新していくもの。
n DDDではチーム全体でユビキタス⾔語を作り上げることでシステムを発展させる。

View Slide

32
ドメイン駆動設計の特徴は、共通の⾔葉を使いながらシステムを発展させる⼿法
＝ユビキタス⾔語を使いながらシステムを発展させる⼿法
ただし、DDDはいつでも万能に使える⼿法というわけではないので、使い所は⾒極める必要がある。
システムの複雑度合い、不確定度合いによって判断する。
• ⾊々な設計⼿法
• アナリシスパターン
• 著者︓マーチン・ファウラー
• ドメインモデルを作り上げるときの具体的な例をパターン化したもの
• デザインパターン
• 著者︓ GoF（Gang of Four）と呼ばれる4⼈の共著者（エーリヒ・ガンマ、リチャード・ヘルム、
ラルフ・ジョンソン、ジョン・ブリシディース）
• オブジェクト指向設計でプログラマーが繰り返し直⾯した問題をどう解決してきたか、パターン化したもの
いろいろな設計開発の⼿法
https://www.amazon.co.jp/オブジェクト
指向における再利用のためのデザイン
パターン-エリック-ガンマ
/dp/4797311126
https://www.amazon.co.jp/アナリシスパターン―再利用
可能なオブジェクトモデル/dp/4795297258

View Slide

33
まとめ
n DDD超概要
- DDDとは
- DDDの関⼼の⾼まり
n ドメインって何︖
- ドメインに興味を持とう
- ドメインを分析する
n ドメインモデルを作ってみよう
n DDDで挫折しそうになった話
n いろいろな設計開発の⼿法

View Slide

34
免責事項
n IBM Developer Dojoは、IBM Cloudを主とした技術情報をお伝えする⽬的で開催しています。講師や運営ス
タッフにより、開催毎に最適と判断した内容でお届けしています。
n 現在、ハンズオンを伴う講義はお客様の費⽤負担がない環境と⼿順でご案内しています。講義終了後、不要と
なったサービスはお客様ご⾃⾝で削除をお願いいたします。
n 本資料の記載内容は可能な限り正確を期しておりますが、正式なレビューを受けておらず、当資料に記載され
た内容を保証するものではありません。
n また、記載されている内容が将来的に変更になる可能性もございます点を何卒ご了承ください。
n 本⽇はご参加いただき、誠にありがとうございました。

View Slide

35

View Slide

IBM Dojo 挫折しないドメイン駆動設計 20210825pm

IBM Dojo 挫折しないドメイン駆動設計 20210825pm

Yuriko Matsuyama

Other Decks in Design

Featured

Transcript