DDD関連のフレーズから入るざっくりDDD超入門 / Roughly DDD Learn,Starting with DDD-related Phrases

社内勉強会で喋ったときにつかったスライドの手直し版です。

下記、資料内に登場するリンクです。

ドメインモデルのつくり方 #5000dai - Speaker Deck
https://speakerdeck.com/a_suenami/domeinmoderufalsetukurifang-number-5000dai

[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html

Transcript

1. DDD関連のフレーズから入る ざっくりDDD超入門 社内勉強会 2023/05/09 しんくう@shinkufencer
2. 今回しゃべること 2 • ドメイン駆動設計(Domain Driven Design)でよくわからんの がとっつきにくいフレーズ群なのでフレーズベースで紹介 • ざっと今回のスライドでDDDの根幹がわかるようになるのを 目指しています
3. ドメイン 3
4. ドメイン • DDDでいうところのドメインは『業務領域』を表し、英単語domainの直 訳する所の意味に近い • たとえば「会計ソフトウェア」を作っていたら、そのソフトウェアのドメ インは「会計業務」などになる • そのため業務の知識のことを『ドメイン知識』などと呼ぶこともある 4
5. ドメインエキスパート 5
6. ドメインエキスパート • 文字通り、そのドメインに精通した人物のことを指す。 ◦ 「会計ソフトウェア」であれば取り扱う会計の知識に詳しい「会計士」だったり ◦ 「オンライン書店のウェブアプリ」であれば「書店員」だったり • ドメインに精通=専門家とは限らない、ドメインに詳しい人はユーザだっ たりするケースもある • たとえ話であがるのは『10年以上アナログでやってきた運送会社』をシス テム化する際のドメインエキスパートは”社長”や”係長”ではなく、いろい ろな書類仕事をしている”事務のおばちゃん”であったりするということ • なお新規プロダクトにはドメインエキスパートは存在しないこともある 6
7. ドメインモデル 7
8. ドメインモデル • ドメインをモデリングしていったもの • 例えば「WEBメディアサイト」の場合は「記事」や「特集」などのドメイ ンモデルとしてモデリングできる • けど、そもそも”モデリング”ってなんでしたっけ？ 8
9. モデリング • モデルに関してはすえなみさんの見解がしっくりきやすい 9 ドメインモデルのつくり方 #5000dai - Speaker Deck https://speakerdeck.com/a_suenami/domeinmoderufalsetukurifang-number-5000dai
10. モデリングとドメインモデル • モデルとは「解決したい問題領域から必要とする要素を抜き出したもの」 なので、モデリングはそれを見つけ出す行動 • ドメインモデルは「ドメイン」に関して「解決したい問題領域から必要と する要素を抜き出したもの」 • WEBメディアサイトも「記事の著者の好きな食べ物」なども要素としては 考えられる。これはグルメ情報を扱うメディアでは必要だが、映画情報を 扱うメディアでは必要ではない。 • 純粋に情報だけではなく振る舞いもモデルには必要になる • このようなドメインモデルはドメインエキスパートらとの会話で形作られ ていく 10
11. ユビキタス言語 11
12. ユビキタス言語 • ドメインエキスパートや開発者を含めたチーム全員で作り上げる共通言語 ◦ ubiquitousは「偏在する」という意味なので、”偏在する言葉”というニュアンスでもある • そのドメインを特徴づけるフレーズや動詞などがユビキタス言語として表 される • WEBメディアサイトであれば「記事」や「著者」などそのドメインを表す ものがユビキタス言語として現れる • 用語集のように囚われがちだが、もとの英単語のニュアンスどおり「活き て偏在する言葉」なので日頃から変化していく活きた言葉のことを指す 12
13. ここまでのフレーズを踏まえ ドメイン駆動設計とは 13
14. ドメイン駆動設計とは 14 DDDとはどんな設計思想かを簡潔に説明すると、ドメインモデルをソフトウェア開発の 中心にすえ、コードやコミュニケーションを常にドメインモデルと一体化させながら、 ドメインモデルを反復的に深化させることでより価値の高いアプリケーションを生み出 していこうとする考え方です。 - [ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場　　　　　 https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html　　　　　 “ ”
15. ドメイン駆動設計とは 15 ここまでのフレーズベースで言い換えると • 開発者とドメインエキスパートと対話をし、ドメインを構成するユビキタ ス言語を確立しドメインモデルを作り上げる • ドメインモデルをドメイン知識を深めていくことにより改善させていく • ドメインモデルと実装コードが対応付けられるようにしていく
16. ドメイン駆動設計とは - 戦略的設計 16 ここまでのフレーズベースで言い換えると • 開発者とドメインエキスパートと対話をし、ドメインを構成するユビキタ ス言語を確立しドメインモデルを作り上げる • ドメインモデルをドメイン知識を深めていくことにより改善させていく • ドメインモデルと実装コードが対応付けられるようにしていく このドメインモデルを作り上げ、洗練していく部分のことを 「戦略的設計」や「戦略的DDD」などと表現することがある ※この用語自体は後天的に発生した言葉
17. ドメイン駆動設計とは - 戦術的設計 17 ここまでのフレーズベースで言い換えると • 開発者とドメインエキスパートと対話をし、ドメインを構成するユビキタ ス言語を確立しドメインモデルを作り上げる • ドメインモデルをドメイン知識を深めていくことにより改善させていく • ドメインモデルと実装コードが対応付けられるようにしていく 戦術的DDDに対し、ドメインモデルを実体のプログラムコードにどう反映していくかの部 分がこちらの内容の中心になる。そのため戦略という表現になぞらえて 「戦術的設計」や「戦術的DDD」などと表現することがある ※戦略のほうが重厚であると捉え、戦術的DDDを「軽量DDD」と呼ぶこともある
18. ここから戦略的DDD寄りの 頻出フレーズを紹介 18
19. 境界づけられたコンテキスト 19
20. 境界づけられたコンテキスト(bounded context) • 複雑なシステムになるとドメインモデル間の連携も複雑化していく、ドメ インモデルとしてもよく似ているが違うドメインモデルなどが登場してく るケースがある • そのためドメインモデルを適切に運用するために「コンテキスト」という 概念が存在する • contextは和訳すると『文脈』と訳せるが、概ねDDDにおいてもニュアン スとしてはあっており、適切に切り分けるための概念として存在してい る。 • 境界づけられたコンテキストは、ドメインモデルが適用できる範囲を区別 ための考え方 20
21. 境界づけられたコンテキスト(bounded context) • ECシステムにおいての例、「商品」とドメインモデルがある場合にコン テキストによって意味がことなる • 商品というドメインモデルでもEC画面と配送で気にするものが変わる 21 Webの販売画面では商品の情報としてほしいのは、『値 段』や『品名』などの情報 配送時に商品の情報としてほしいのは、『ダンボールの どのサイズに入るか』『重さ』などの情報 商品 [値段][品名] [重量][ﾀﾞﾝﾎﾞｰﾙｻｲｽﾞ]
22. 販売コンテキスト 境界づけられたコンテキスト(bounded context) • 境界づけられたコンテキストを設けて、同じ商品でも違うドメインモデル であることをわかりやすくする • 下記の例だと「販売」と「配送」でコンテキストを分けて、それぞれのコ ンテキストで別の「商品ドメインモデル」をもつ 22 商品 [値段][品名] 配送コンテキスト 商品 [重量][ﾀﾞﾝﾎﾞｰﾙｻｲｽﾞ]
23. コンテキストマップ 23
24. コンテキストマップ • １つのアプリケーションで複数のコンテキストを持つのでそこには関係性 ができる • そのコンテキスト同士に関してのフレーズがいくつかあるが、2つのパ ターングループに大まかに分類できる • 複数のコンテキスト同士の関係性を説明する「組織パターン」 • コンテキスト同士の繋がりの方法を示す「結合パターン」 • それぞれのパターンに関してざっくり紹介する 24
25. コンテキストマップの 組織パターン 25
26. 組織パターン - 『順応者』 26 Amazon Pay コンテキスト • 上流にいるコンテキストが下流側にあるコンテキストの要望に答えて変更 しない状態 • 下記の例の場合はAmazonの仕様に従ってWeb販売サービスの販売コンテ キストを使う場合の例 販売 コンテキスト 順応者
27. 商品 コンテキスト 組織パターン - 『顧客／供給者の開発チーム』 • 供給者が上位、顧客が下位となる関係性のコンテキスト • 順応者と似ているが、こちらは下位の要求を上位が受け付けられる関係性 • 下記例で商品というコンテキストで連結はしているが、販売コンテキスト 側からの仕様変更は柔軟に受け付ける 27 販売 コンテキスト 顧客 供給者
28. 販売イベント コンテキスト 組織パターン - 『別々の道』 • そもそも関係性を持たないということを表現したもの • 「一見すると関連性がありそうな2つのコンテキストを連携させようとし たが連携するメリットがそんなになさそう」のようなシチュエーションで 使われる • 下記の例だと「販売促進のための街頭イベント」のコンテキストと「販売 コンテキスト」は近そうだが無理に連携はしない ◦ 結合パターンの話と交えるとよりこの言葉の使い所がわかりやすい 28 販売 コンテキスト
29. コンテキストマップの 結合パターン 29
30. 結合パターン - 『共有カーネル』 30 運送 コンテキスト • 異なるコンテキストだが、モデル・ソースコード・DBスキーマなどの一 部のものを共有するパターン • 共有カーネルとして扱う部分は特別なものになるため勝手に変更しないな どの制約が必要 • 例えば以下のように販売のときの費用や送料の費用を計算するときのソー スコード共有などが例としてあげられる 販売 コンテキスト 送料計算 ロジック の ソース コード
31. 結合パターン - 『公開ホストサービス』 31 地図情報 コンテキスト • コンテキストにアクセスする際のプロトコルを決めて、個々のコンテキス ト同士のつながりを独自に決めなくても良いようにするパターン • 昨今のWebAPIはこのパターンの類似の考え方で、サービスの連携はREST 形式のフォーマットで行い、上流のコンテキストがそのプロトコルを提供 する 店舗情報 コンテキスト REST API 経路案内 コンテキスト
32. 販売 コンテキスト 結合パターン - 『腐敗防止層』 • 連携したいが、そのままの状態で連携をすると両者のコンテキストでふさ わしくない状態になる可能性がある場合に、そのふさわしくない状態が伝 搬しないためのレイヤをつくるパターン • 例えば元からCRUDの要素で連携ができるコンテキストがあるが、それを そのまま使われると困るのでReadのみに絞るインターフェイスを用意す るなど 32 平成版旧販売 コンテキスト 影響のない 情報参照 のみできる REST API
33. まとめ 33 • ドメイン駆動設計の根底は問題領域を分析して、その知識を 深めつつ昇華させていく設計手法 • ただ言葉のとっつきにくさは大いにあるので、これを足がか りに本を読んでもらえれば幸い