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

by ShinkuFencer

Slide 1

Slide 1 text

DDD関連のフレーズから入るざっくりDDD超入門社内勉強会 2023/05/09 しんくう@shinkufencer

Slide 2

Slide 2 text

今回しゃべること 2 ● ドメイン駆動設計(Domain Driven Design)でよくわからんのがとっつきにくいフレーズ群なのでフレーズベースで紹介 ● ざっと今回のスライドでDDDの根幹がわかるようになるのを目指しています

Slide 3

Slide 3 text

ドメイン 3

Slide 4

Slide 4 text

ドメイン ● DDDでいうところのドメインは『業務領域』を表し、英単語domainの直訳する所の意味に近い ● たとえば「会計ソフトウェア」を作っていたら、そのソフトウェアのドメインは「会計業務」などになる ● そのため業務の知識のことを『ドメイン知識』などと呼ぶこともある 4

Slide 5

Slide 5 text

ドメインエキスパート 5

Slide 6

Slide 6 text

ドメインエキスパート ● 文字通り、そのドメインに精通した人物のことを指す。 ○ 「会計ソフトウェア」であれば取り扱う会計の知識に詳しい「会計士」だったり ○ 「オンライン書店のウェブアプリ」であれば「書店員」だったり ● ドメインに精通=専門家とは限らない、ドメインに詳しい人はユーザだったりするケースもある ● たとえ話であがるのは『10年以上アナログでやってきた運送会社』をシステム化する際のドメインエキスパートは”社長”や”係長”ではなく、いろいろな書類仕事をしている”事務のおばちゃん”であったりするということ ● なお新規プロダクトにはドメインエキスパートは存在しないこともある 6

Slide 7

Slide 7 text

ドメインモデル 7

Slide 8

Slide 8 text

ドメインモデル ● ドメインをモデリングしていったもの ● 例えば「WEBメディアサイト」の場合は「記事」や「特集」などのドメインモデルとしてモデリングできる ● けど、そもそも”モデリング”ってなんでしたっけ？ 8

Slide 9

Slide 9 text

モデリング ● モデルに関してはすえなみさんの見解がしっくりきやすい 9 ドメインモデルのつくり方 #5000dai - Speaker Deck https://speakerdeck.com/a_suenami/domeinmoderufalsetukurifang-number-5000dai

Slide 10

Slide 10 text

モデリングとドメインモデル ● モデルとは「解決したい問題領域から必要とする要素を抜き出したもの」なので、モデリングはそれを見つけ出す行動 ● ドメインモデルは「ドメイン」に関して「解決したい問題領域から必要とする要素を抜き出したもの」 ● WEBメディアサイトも「記事の著者の好きな食べ物」なども要素としては考えられる。これはグルメ情報を扱うメディアでは必要だが、映画情報を扱うメディアでは必要ではない。 ● 純粋に情報だけではなく振る舞いもモデルには必要になる ● このようなドメインモデルはドメインエキスパートらとの会話で形作られていく 10

Slide 11

Slide 11 text

ユビキタス言語 11

Slide 12

Slide 12 text

ユビキタス言語 ● ドメインエキスパートや開発者を含めたチーム全員で作り上げる共通言語 ○ ubiquitousは「偏在する」という意味なので、”偏在する言葉”というニュアンスでもある ● そのドメインを特徴づけるフレーズや動詞などがユビキタス言語として表される ● WEBメディアサイトであれば「記事」や「著者」などそのドメインを表すものがユビキタス言語として現れる ● 用語集のように囚われがちだが、もとの英単語のニュアンスどおり「活きて偏在する言葉」なので日頃から変化していく活きた言葉のことを指す 12

Slide 13

Slide 13 text

ここまでのフレーズを踏まえドメイン駆動設計とは 13

Slide 14

Slide 14 text

ドメイン駆動設計とは 14 DDDとはどんな設計思想かを簡潔に説明すると、ドメインモデルをソフトウェア開発の中心にすえ、コードやコミュニケーションを常にドメインモデルと一体化させながら、ドメインモデルを反復的に深化させることでより価値の高いアプリケーションを生み出していこうとする考え方です。 - [ 技術講座 ] Domain-Driven Designのエッセンス第1回｜オブジェクトの広場　　　　　 https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/chap1.html　　　　　 “ ”

Slide 15

Slide 15 text

ドメイン駆動設計とは 15 ここまでのフレーズベースで言い換えると ● 開発者とドメインエキスパートと対話をし、ドメインを構成するユビキタス言語を確立しドメインモデルを作り上げる ● ドメインモデルをドメイン知識を深めていくことにより改善させていく ● ドメインモデルと実装コードが対応付けられるようにしていく

Slide 16

Slide 16 text

ドメイン駆動設計とは - 戦略的設計 16 ここまでのフレーズベースで言い換えると ● 開発者とドメインエキスパートと対話をし、ドメインを構成するユビキタス言語を確立しドメインモデルを作り上げる ● ドメインモデルをドメイン知識を深めていくことにより改善させていく ● ドメインモデルと実装コードが対応付けられるようにしていくこのドメインモデルを作り上げ、洗練していく部分のことを「戦略的設計」や「戦略的DDD」などと表現することがある ※この用語自体は後天的に発生した言葉

Slide 17

Slide 17 text

ドメイン駆動設計とは - 戦術的設計 17 ここまでのフレーズベースで言い換えると ● 開発者とドメインエキスパートと対話をし、ドメインを構成するユビキタス言語を確立しドメインモデルを作り上げる ● ドメインモデルをドメイン知識を深めていくことにより改善させていく ● ドメインモデルと実装コードが対応付けられるようにしていく戦術的DDDに対し、ドメインモデルを実体のプログラムコードにどう反映していくかの部分がこちらの内容の中心になる。そのため戦略という表現になぞらえて「戦術的設計」や「戦術的DDD」などと表現することがある ※戦略のほうが重厚であると捉え、戦術的DDDを「軽量DDD」と呼ぶこともある

Slide 18

Slide 18 text

ここから戦略的DDD寄りの頻出フレーズを紹介 18

Slide 19

Slide 19 text

境界づけられたコンテキスト 19

Slide 20

Slide 20 text

境界づけられたコンテキスト(bounded context) ● 複雑なシステムになるとドメインモデル間の連携も複雑化していく、ドメインモデルとしてもよく似ているが違うドメインモデルなどが登場してくるケースがある ● そのためドメインモデルを適切に運用するために「コンテキスト」という概念が存在する ● contextは和訳すると『文脈』と訳せるが、概ねDDDにおいてもニュアンスとしてはあっており、適切に切り分けるための概念として存在している。 ● 境界づけられたコンテキストは、ドメインモデルが適用できる範囲を区別ための考え方 20

Slide 21

Slide 21 text

境界づけられたコンテキスト(bounded context) ● ECシステムにおいての例、「商品」とドメインモデルがある場合にコンテキストによって意味がことなる ● 商品というドメインモデルでもEC画面と配送で気にするものが変わる 21 Webの販売画面では商品の情報としてほしいのは、『値段』や『品名』などの情報配送時に商品の情報としてほしいのは、『ダンボールのどのサイズに入るか』『重さ』などの情報商品 [値段][品名] [重量][ﾀﾞﾝﾎﾞｰﾙｻｲｽﾞ]

Slide 22

Slide 22 text

販売コンテキスト境界づけられたコンテキスト(bounded context) ● 境界づけられたコンテキストを設けて、同じ商品でも違うドメインモデルであることをわかりやすくする ● 下記の例だと「販売」と「配送」でコンテキストを分けて、それぞれのコンテキストで別の「商品ドメインモデル」をもつ 22 商品 [値段][品名] 配送コンテキスト商品 [重量][ﾀﾞﾝﾎﾞｰﾙｻｲｽﾞ]

Slide 23

Slide 23 text

コンテキストマップ 23

Slide 24

Slide 24 text

コンテキストマップ ● １つのアプリケーションで複数のコンテキストを持つのでそこには関係性ができる ● そのコンテキスト同士に関してのフレーズがいくつかあるが、2つのパターングループに大まかに分類できる ● 複数のコンテキスト同士の関係性を説明する「組織パターン」 ● コンテキスト同士の繋がりの方法を示す「結合パターン」 ● それぞれのパターンに関してざっくり紹介する 24

Slide 25

Slide 25 text

コンテキストマップの組織パターン 25

Slide 26

Slide 26 text

組織パターン - 『順応者』 26 Amazon Pay コンテキスト ● 上流にいるコンテキストが下流側にあるコンテキストの要望に答えて変更しない状態 ● 下記の例の場合はAmazonの仕様に従ってWeb販売サービスの販売コンテキストを使う場合の例販売コンテキスト順応者

Slide 27

Slide 27 text

商品コンテキスト組織パターン - 『顧客／供給者の開発チーム』 ● 供給者が上位、顧客が下位となる関係性のコンテキスト ● 順応者と似ているが、こちらは下位の要求を上位が受け付けられる関係性 ● 下記例で商品というコンテキストで連結はしているが、販売コンテキスト側からの仕様変更は柔軟に受け付ける 27 販売コンテキスト顧客供給者

Slide 28

Slide 28 text

販売イベントコンテキスト組織パターン - 『別々の道』 ● そもそも関係性を持たないということを表現したもの ● 「一見すると関連性がありそうな2つのコンテキストを連携させようとしたが連携するメリットがそんなになさそう」のようなシチュエーションで使われる ● 下記の例だと「販売促進のための街頭イベント」のコンテキストと「販売コンテキスト」は近そうだが無理に連携はしない ○ 結合パターンの話と交えるとよりこの言葉の使い所がわかりやすい 28 販売コンテキスト

Slide 29

Slide 29 text

コンテキストマップの結合パターン 29

Slide 30

Slide 30 text

結合パターン - 『共有カーネル』 30 運送コンテキスト ● 異なるコンテキストだが、モデル・ソースコード・DBスキーマなどの一部のものを共有するパターン ● 共有カーネルとして扱う部分は特別なものになるため勝手に変更しないなどの制約が必要 ● 例えば以下のように販売のときの費用や送料の費用を計算するときのソースコード共有などが例としてあげられる販売コンテキスト送料計算ロジックのソースコード

Slide 31

Slide 31 text

結合パターン - 『公開ホストサービス』 31 地図情報コンテキスト ● コンテキストにアクセスする際のプロトコルを決めて、個々のコンテキスト同士のつながりを独自に決めなくても良いようにするパターン ● 昨今のWebAPIはこのパターンの類似の考え方で、サービスの連携はREST 形式のフォーマットで行い、上流のコンテキストがそのプロトコルを提供する店舗情報コンテキスト REST API 経路案内コンテキスト

Slide 32

Slide 32 text

販売コンテキスト結合パターン - 『腐敗防止層』 ● 連携したいが、そのままの状態で連携をすると両者のコンテキストでふさわしくない状態になる可能性がある場合に、そのふさわしくない状態が伝搬しないためのレイヤをつくるパターン ● 例えば元からCRUDの要素で連携ができるコンテキストがあるが、それをそのまま使われると困るのでReadのみに絞るインターフェイスを用意するなど 32 平成版旧販売コンテキスト影響のない情報参照のみできる REST API

Slide 33

Slide 33 text

まとめ 33 ● ドメイン駆動設計の根底は問題領域を分析して、その知識を深めつつ昇華させていく設計手法 ● ただ言葉のとっつきにくさは大いにあるので、これを足がかりに本を読んでもらえれば幸い