Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「境界付けられたコンテキスト間の関係」についてもっと語ろう
Search
acomagu
September 08, 2024
Technology
0
93
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
September 08, 2024
Tweet
Share
More Decks by acomagu
See All by acomagu
Stripe SSoT をするべきか否か
acomagu
0
50
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
91
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
300
Stripe リコンサイルの勘所
acomagu
0
480
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2.2k
AWS CDK を支える Constructs について
acomagu
0
170
DDDとは結局何なのか
acomagu
0
310
API Gateway HTTP API について
acomagu
0
140
JP_Stripes: 一貫性に寄与する設計
acomagu
0
96
Other Decks in Technology
See All in Technology
帳票Vibe Coding
terurou
0
140
JOAI発表資料 @ 関東kaggler会
joai_committee
1
350
自社製CMSからmicroCMSへのリプレースがプロダクトグロースを加速させた話
nextbeatdev
0
140
生成AI利用プログラミング:誰でもプログラムが書けると 世の中どうなる?/opencampus202508
okana2ki
0
190
.NET開発者のためのAzureの概要
tomokusaba
0
230
MySQL HeatWave:サービス概要のご紹介
oracle4engineer
PRO
4
1.7k
事業価値と Engineering
recruitengineers
PRO
2
230
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
2
200
Amazon Bedrock AgentCore でプロモーション用動画生成エージェントを開発する
nasuvitz
6
430
あなたの知らない OneDrive
murachiakira
0
240
新卒(ほぼ)専業Kagglerという選択肢
nocchi1
1
2.4k
JavaScript 研修
recruitengineers
PRO
3
180
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
53
7.7k
Documentation Writing (for coders)
carmenintech
73
5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Faster Mobile Websites
deanohume
309
31k
KATA
mclloyd
32
14k
Music & Morning Musume
bryan
46
6.7k
Bash Introduction
62gerente
614
210k
The Language of Interfaces
destraynor
160
25k
Building an army of robots
kneath
306
46k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
480
How to train your dragon (web standard)
notwaldorf
96
6.2k
Transcript
「境界付けられた コンテキスト間の関係」 についてもっと語ろう @acomagu 240907
自己紹介 - @acomagu github.com/acomagu - s1230004 - 株式会社デザイニウムで主に TS を書いています
- 最近はスプラトゥーンにハマっています - 会津に帰りたい - 入っていたサークル: Zli / 合唱部
もくじ 1. BC(境界付けられたコンテキスト)は身近である 2. BC 間の関係の種類 3. 知っておくと何がいいのか?
BC(境界付けられたコンテキスト) は身近である
BC(境界付けられたコンテキスト)とは? 「チームの形がシステムの形を決める」(逆コンウェイの法則) ≒ コミュニケーションの境界が技術の境界になる DDD「1つの境界付けられたコンテキストに複数のチームが取り組むのは、(不可能とは 言わないが)難しい」 →チームの境界あるところにコンテキスト境界あり - チームが異なる
- ユビキタス言語が異なる - 目的が異なる ↑別 BC のサイン
BC(境界付けられたコンテキスト)とは? フロントエンド/サーバーサイドは別境界 ライブラリは別境界 SaaS/BaaS は別境界
BC(境界付けられたコンテキスト)とは? フロントエンド/サーバーサイドは別境界 ライブラリは別境界 SaaS/BaaS は別境界 Stripe サーバーサイド フロントエンド BC BC
BC レガシー サーバーサイド BC
BC 間の関係の種類 それぞれざっくり
BC 間の関係の種類①: 共有カーネル 一部モデル(ソースコード)が共有されている関係 初期は開発が速く進みやすい (インフラ等ドメイン外の共有については共有カーネルとは言わない)
BC 間の関係の種類②: 顧客/供給者の関係 > 二つの開発チームに上流/下流関係があり、上流のチームが成功するかどうかが下 流の結果に左右されうる場合 (IDDD) > 一方のサブシステムが、本質的にもう一方のサブシステムに対して入力を与える関係 の場合
(DDD) 「下流が上流を使う」ような、依存関係だと解釈しています。 供給者には、顧客の要求が重要であり、要求に答えるモチベーションがある 例: (JSON 色付け的な)サーバーサイド/フロントエンド
BC 間の関係の種類③: 順応者 二つの開発チームに上流/下流関係があるが、 上流には、下流の要求に答えるモチベーションがそこまでないが しかし “上流の設計の品質がそれほど悪くなく、スタイルもそれなりに互換性がある場 合” つまり、「上流のモデルを流用する」
BC 間の関係の種類④: 腐敗防止層 一方が本質的にもう一方の入力となるが、 上流には、顧客の要求に答えるモチベーションがそこまでないが しかし “カプセル化の欠如や、ぎこちない抽象、下流チームでは使用できないパラダイ ムを用いたモデリングなどにより、その設計を扱うのが難しすぎる場合、下流チームは やはり独自のモデルを開発する必要がある” つまり「上流がイケてないので、上流とは別のモデルを作る」
BC 間の関係の種類⑤: 別々の道 統合しない 別サービスとしてビルドする (e.g. ユーザーが使いたいサービスをメニューから選ぶ、など)
この図ではそれぞれどんな関係だろう? Stripe サーバーサイド フロントエンド BC BC BC レガシー サーバーサイド BC
この図ではそれぞれどんな関係だろう? Stripe サーバーサイド フロントエンド BC BC BC レガシー サーバーサイド BC
順応者 腐敗防止層 顧客/供給者 ※一例
知っておくと何がいいのか
知っておくと何がいいのか 多分一人で開発している場合にはあまり考えなくても問題にならない 別の人に「この別システム/ライブラリをコード上でどう扱うか」という態度を説明したいと きに役に立つ
知っておくと何がいいのか? 例えば「アプリケーションにライブラリ A とライブラリ B を統合する場合」 アプリケーション B A 「A
はドメインから直接使うが、B は一旦インフラを挟みたい...」 →なぜ?(レビューで指摘されたと思ってください) (例えば、 A は日付ライブラリで B は何かの SDK)
知っておくと何がいいのか? A は「モデルがイケてるので、ドメインが直接触るほうがいい」 > 上流チームのモデルに隷属することで生じる、境界付けられたコンテキスト感での複 雑な変換を取り除くこと。確かに下流の設計者がとれるスタイルは制限され、そのアプリ ケーションにとって理想的なモデルが作れなくなるかもしれないが、順応することを選ぶ ことで統合は大幅に簡略化されるのだ。
知っておくと何がいいのか? B は「モデルの一部分しか使わないので、腐敗防止層を通してこちら側のモデルに適用 したい」
知っておくと何がいいのか 他にも、フロントエンドのバックエンドの関係において、「顧客/供給者の関係を目指し て、テストをしっかりバックエンドで用意したほうがいい」という会話ができるかも
大切なのは語彙を増やすこと - 「DDD 本のパターンに従うべき」なんて今どきみんな食傷していて(私も)、そんなこ とよりもっと自分のプロダクトを見つめたほうがいい - このあたりは「DDD とは結局何なのか(acomagu SpeakerDeck にあります)」も良ければ見てみてく
ださい - しかし、まさに自分が書くソースコードの構成要素について、チーム内で話せる共 通語彙が増えるのはいいこと - DDD 本や IDDD 本には今回紹介した関係性それぞれについてもっといろいろな ケースが載っている 「DDD」というだけで拒絶するのではなく、その部分だけでも読んでみてみてください
みなさんも自分のソースコードについて BC を見つけ BC 間の関係を考えてみてください ありがとうございました!