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
51
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
September 08, 2024
Tweet
Share
More Decks by acomagu
See All by acomagu
Stripe SSoT をするべきか否か
acomagu
0
22
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
54
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
180
Stripe リコンサイルの勘所
acomagu
0
350
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
2k
AWS CDK を支える Constructs について
acomagu
0
150
DDDとは結局何なのか
acomagu
0
250
API Gateway HTTP API について
acomagu
0
120
JP_Stripes: 一貫性に寄与する設計
acomagu
0
83
Other Decks in Technology
See All in Technology
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
re:Invent をおうちで楽しんでみた ~CloudWatch のオブザーバビリティ機能がスゴい!/ Enjoyed AWS re:Invent from Home and CloudWatch Observability Feature is Amazing!
yuj1osm
0
120
多領域インシデントマネジメントへの挑戦:ハードウェアとソフトウェアの融合が生む課題/Challenge to multidisciplinary incident management: Issues created by the fusion of hardware and software
bitkey
PRO
2
100
複雑性の高いオブジェクト編集に向き合う: プラガブルなReactフォーム設計
righttouch
PRO
0
110
5分でわかるDuckDB
chanyou0311
10
3.2k
1等無人航空機操縦士一発試験 合格までの道のり ドローンミートアップ@大阪 2024/12/18
excdinc
0
150
DevOps視点でAWS re:invent2024の新サービス・アプデを振り返ってみた
oshanqq
0
180
OpenShift Virtualizationのネットワーク構成を真剣に考えてみた/OpenShift Virtualization's Network Configuration
tnk4on
0
130
OpenAIの蒸留機能(Model Distillation)を使用して運用中のLLMのコストを削減する取り組み
pharma_x_tech
4
540
ガバメントクラウドのセキュリティ対策事例について
fujisawaryohei
0
530
ゼロから創る横断SREチーム 挑戦と進化の軌跡
rvirus0817
2
260
10個のフィルタをAXI4-Streamでつなげてみた
marsee101
0
160
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Producing Creativity
orderedlist
PRO
341
39k
Designing for Performance
lara
604
68k
KATA
mclloyd
29
14k
Designing on Purpose - Digital PM Summit 2013
jponch
116
7k
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
Into the Great Unknown - MozCon
thekraken
33
1.5k
Making the Leap to Tech Lead
cromwellryan
133
9k
Done Done
chrislema
181
16k
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 間の関係を考えてみてください ありがとうございました!