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
Go で言うところのアレは TypeScript で言うとコレ / Kyoto.なんか #7
susisu
7
1.8k
Android Studio の 新しいAI機能を試してみよう / Try out the new AI features in Android Studio
yanzm
0
270
株式会社ARAV 採用案内
maqui
0
350
Amazon Bedrock AgentCore でプロモーション用動画生成エージェントを開発する
nasuvitz
6
430
退屈なことはDevinにやらせよう〜〜Devin APIを使ったVisual Regression Testの自動追加〜
kawamataryo
3
650
Postman MCP 関連機能アップデート / Postman MCP feature updates
yokawasa
0
150
VPC Latticeのサービスエンドポイント機能を使用した複数VPCアクセス
duelist2020jp
0
240
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
3
200
JuniorからSeniorまで: DevOpsエンジニアの成長ロードマップ
yuriemori
0
210
Devinを使ったモバイルアプリ開発 / Mobile app development with Devin
yanzm
0
190
自社製CMSからmicroCMSへのリプレースがプロダクトグロースを加速させた話
nextbeatdev
0
140
実践データベース設計 ①データベース設計概論
recruitengineers
PRO
3
250
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
45
7.6k
Gamification - CAS2011
davidbonilla
81
5.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The Cult of Friendly URLs
andyhume
79
6.5k
Into the Great Unknown - MozCon
thekraken
40
2k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
GraphQLとの向き合い方2022年版
quramy
49
14k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
820
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.5k
Being A Developer After 40
akosma
90
590k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.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 間の関係を考えてみてください ありがとうございました!