Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

ShinkuFencer

May 24, 2023
Tweet

More Decks by ShinkuFencer

Other Decks in Technology

Transcript

  1. ドメインエキスパート • 文字通り、そのドメインに精通した人物のことを指す。 ◦ 「会計ソフトウェア」であれば取り扱う会計の知識に詳しい「会計士」だったり ◦ 「オンライン書店のウェブアプリ」であれば「書店員」だったり • ドメインに精通=専門家とは限らない、ドメインに詳しい人はユーザだっ たりするケースもある

    • たとえ話であがるのは『10年以上アナログでやってきた運送会社』をシス テム化する際のドメインエキスパートは”社長”や”係長”ではなく、いろい ろな書類仕事をしている”事務のおばちゃん”であったりするということ • なお新規プロダクトにはドメインエキスパートは存在しないこともある 6
  2. ドメイン駆動設計とは - 戦略的設計 16 ここまでのフレーズベースで言い換えると • 開発者とドメインエキスパートと対話をし、ドメインを構成するユビキタ ス言語を確立しドメインモデルを作り上げる • ドメインモデルをドメイン知識を深めていくことにより改善させていく

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

    • ドメインモデルと実装コードが対応付けられるようにしていく 戦術的DDDに対し、ドメインモデルを実体のプログラムコードにどう反映していくかの部 分がこちらの内容の中心になる。そのため戦略という表現になぞらえて 「戦術的設計」や「戦術的DDD」などと表現することがある ※戦略のほうが重厚であると捉え、戦術的DDDを「軽量DDD」と呼ぶこともある
  4. 境界づけられたコンテキスト(bounded context) • 複雑なシステムになるとドメインモデル間の連携も複雑化していく、ドメ インモデルとしてもよく似ているが違うドメインモデルなどが登場してく るケースがある • そのためドメインモデルを適切に運用するために「コンテキスト」という 概念が存在する •

    contextは和訳すると『文脈』と訳せるが、概ねDDDにおいてもニュアン スとしてはあっており、適切に切り分けるための概念として存在してい る。 • 境界づけられたコンテキストは、ドメインモデルが適用できる範囲を区別 ための考え方 20
  5. 組織パターン - 『順応者』 26 Amazon Pay コンテキスト • 上流にいるコンテキストが下流側にあるコンテキストの要望に答えて変更 しない状態

    • 下記の例の場合はAmazonの仕様に従ってWeb販売サービスの販売コンテ キストを使う場合の例 販売 コンテキスト 順応者
  6. 商品 コンテキスト 組織パターン - 『顧客/供給者の開発チーム』 • 供給者が上位、顧客が下位となる関係性のコンテキスト • 順応者と似ているが、こちらは下位の要求を上位が受け付けられる関係性 •

    下記例で商品というコンテキストで連結はしているが、販売コンテキスト 側からの仕様変更は柔軟に受け付ける 27 販売 コンテキスト 顧客 供給者
  7. 販売イベント コンテキスト 組織パターン - 『別々の道』 • そもそも関係性を持たないということを表現したもの • 「一見すると関連性がありそうな2つのコンテキストを連携させようとし たが連携するメリットがそんなになさそう」のようなシチュエーションで

    使われる • 下記の例だと「販売促進のための街頭イベント」のコンテキストと「販売 コンテキスト」は近そうだが無理に連携はしない ◦ 結合パターンの話と交えるとよりこの言葉の使い所がわかりやすい 28 販売 コンテキスト
  8. 結合パターン - 『共有カーネル』 30 運送 コンテキスト • 異なるコンテキストだが、モデル・ソースコード・DBスキーマなどの一 部のものを共有するパターン •

    共有カーネルとして扱う部分は特別なものになるため勝手に変更しないな どの制約が必要 • 例えば以下のように販売のときの費用や送料の費用を計算するときのソー スコード共有などが例としてあげられる 販売 コンテキスト 送料計算 ロジック の ソース コード
  9. 結合パターン - 『公開ホストサービス』 31 地図情報 コンテキスト • コンテキストにアクセスする際のプロトコルを決めて、個々のコンテキス ト同士のつながりを独自に決めなくても良いようにするパターン •

    昨今のWebAPIはこのパターンの類似の考え方で、サービスの連携はREST 形式のフォーマットで行い、上流のコンテキストがそのプロトコルを提供 する 店舗情報 コンテキスト REST API 経路案内 コンテキスト
  10. 販売 コンテキスト 結合パターン - 『腐敗防止層』 • 連携したいが、そのままの状態で連携をすると両者のコンテキストでふさ わしくない状態になる可能性がある場合に、そのふさわしくない状態が伝 搬しないためのレイヤをつくるパターン •

    例えば元からCRUDの要素で連携ができるコンテキストがあるが、それを そのまま使われると困るのでReadのみに絞るインターフェイスを用意す るなど 32 平成版旧販売 コンテキスト 影響のない 情報参照 のみできる REST API