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
38
「境界付けられたコンテキスト間の関係」についてもっと語ろう
acomagu
September 08, 2024
Tweet
Share
More Decks by acomagu
See All by acomagu
JP_Stripes: リコンサイル(突合処理)のテスト
acomagu
0
37
地方 MaaS 事例: アプリの進化に伴って変化してきた Stripe 利用方法
acomagu
0
130
Stripe リコンサイルの勘所
acomagu
0
300
CDK 一発で全てのエラーログを Slack に流す
acomagu
0
1.9k
AWS CDK を支える Constructs について
acomagu
0
140
DDDとは結局何なのか
acomagu
0
220
API Gateway HTTP API について
acomagu
0
110
JP_Stripes: 一貫性に寄与する設計
acomagu
0
80
Stripeではじめての決済
acomagu
0
730
Other Decks in Technology
See All in Technology
ADRを運用して3年経った僕らの現在地
onk
PRO
13
5.5k
とある事業会社にとっての Kaggler の魅力
hakubishin3
2
380
Kubernetes Meetup Tokyo #67 - KEP-3619: Fine-grained SupplementalGroups Control / k8sjp67-kep-3619
everpeace
0
130
AWS Lambdaで実現するスケーラブルで低コストなWebサービス構築/YAPC::Hakodate2024
fujiwara3
7
3.4k
ラブグラフ紹介資料 〜プロダクト解体新書〜 / Lovegraph Product Deck
lovegraph
0
14k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
5
47k
Oracle Database 23ai 新機能#4 Rolling Maintenance
oracle4engineer
PRO
0
130
Qdrant を用いた検索改善施策の紹介 / Search Engineering Tech Talk 2024 Summer
visional_engineering_and_design
0
190
入社半年(合計1年)でGoogle Cloud 認定を全冠した秘訣🤫
risatube
1
220
テストコードの品質を客観的な数値で担保しよう〜Mutation Testのすすめ〜
ysknsid25
12
3.2k
KubeVirt Networking ONIC 2024
orimanabu
3
590
クレジットカードを製造する技術
yutadayo
81
48k
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
53
9k
Making the Leap to Tech Lead
cromwellryan
131
8.8k
GraphQLの誤解/rethinking-graphql
sonatard
65
9.9k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Testing 201, or: Great Expectations
jmmastey
38
7k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
228
52k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
How To Stay Up To Date on Web Technology
chriscoyier
787
250k
Optimising Largest Contentful Paint
csswizardry
31
2.8k
Fireside Chat
paigeccino
32
3k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Designing the Hi-DPI Web
ddemaree
280
34k
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 間の関係を考えてみてください ありがとうございました!