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
36
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
September 08, 2024
Tweet
Share
More Decks by acomagu
See All by acomagu
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
120
Stripe リコンサイルの勘所
acomagu
0
290
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
1.9k
AWS CDK を支える Constructs について
acomagu
0
140
DDDとは結局何なのか
acomagu
0
210
API Gateway HTTP API について
acomagu
0
110
JP_Stripes: 一貫性に寄与する設計
acomagu
0
78
Stripeではじめての決済
acomagu
0
720
あなたの知らない(かもしれない)Git
acomagu
2
97
Other Decks in Technology
See All in Technology
テスト”ケース”駆動開発 で手戻りをなくそう
ryohma0510
0
330
不動産 x AIことはじめ~データの真価を拓くために
estie
0
120
watsonx.ai Dojo 環境準備について
oniak3ibm
PRO
0
340
Agile in Automotive Industry, puzzles and lights.
hiranabe
3
1.4k
DroidKaigi 2024 たすけて!ViewModel
mhidaka
5
950
AIを活用した柔軟かつ効率的な社内リソース検索への取り組み
cygames
0
190
JEP 480: Structured Concurrency
aya_ebata
0
130
Discovering AI Models
picardparis
4
3.9k
Creative UIs with Compose: DroidKaigi 2024
chrishorner
1
590
20240912 JJUGナイトセミナー
mii1004
0
140
『GRANBLUE FANTASY: Relink』クオリティと物量の両立に挑戦したフェイシャルアニメーション事例 ~カットシーンからランタイムまで~
cygames
0
100
事前準備が肝!AI活用のための業務改革
layerx
PRO
1
390
Featured
See All Featured
Optimising Largest Contentful Paint
csswizardry
31
2.8k
Designing the Hi-DPI Web
ddemaree
278
34k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.3k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
How to Ace a Technical Interview
jacobian
274
23k
A Philosophy of Restraint
colly
202
16k
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.1k
Writing Fast Ruby
sferik
623
60k
Done Done
chrislema
180
16k
The Invisible Side of Design
smashingmag
296
50k
Teambox: Starting and Learning
jrom
131
8.7k
Raft: Consensus for Rubyists
vanstee
135
6.5k
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 間の関係を考えてみてください ありがとうございました!