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

「境界付けられたコンテキスト間の関係」についてもっと語ろう

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.
Avatar for acomagu acomagu
September 08, 2024

 「境界付けられたコンテキスト間の関係」についてもっと語ろう

Avatar for acomagu

acomagu

September 08, 2024
Tweet

More Decks by acomagu

Other Decks in Technology

Transcript

  1. 自己紹介 - @acomagu github.com/acomagu
 - s1230004
 - 株式会社デザイニウムで主に TS を書いています


    - 最近はスプラトゥーンにハマっています
 - 会津に帰りたい
 - 入っていたサークル: Zli / 合唱部

  2. BC 間の関係の種類②: 顧客/供給者の関係 > 二つの開発チームに上流/下流関係があり、上流のチームが成功するかどうかが下 流の結果に左右されうる場合 (IDDD)
 > 一方のサブシステムが、本質的にもう一方のサブシステムに対して入力を与える関係 の場合

    (DDD)
 「下流が上流を使う」ような、依存関係だと解釈しています。
 供給者には、顧客の要求が重要であり、要求に答えるモチベーションがある
 例: (JSON 色付け的な)サーバーサイド/フロントエンド

  3. 知っておくと何がいいのか? 例えば「アプリケーションにライブラリ A とライブラリ B を統合する場合」
 アプリケーション B A 「A

    はドメインから直接使うが、B は一旦インフラを挟みたい...」 →なぜ?(レビューで指摘されたと思ってください) (例えば、 A は日付ライブラリで B は何かの SDK)
  4. 大切なのは語彙を増やすこと - 「DDD 本のパターンに従うべき」なんて今どきみんな食傷していて(私も)、そんなこ とよりもっと自分のプロダクトを見つめたほうがいい
 - このあたりは「DDD とは結局何なのか(acomagu SpeakerDeck にあります)」も良ければ見てみてく

    ださい
 - しかし、まさに自分が書くソースコードの構成要素について、チーム内で話せる共 通語彙が増えるのはいいこと
 - DDD 本や IDDD 本には今回紹介した関係性それぞれについてもっといろいろな ケースが載っている
 「DDD」というだけで拒絶するのではなく、その部分だけでも読んでみてみてください