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
DDD集約とサービスコンテキスト境界との関係性
Search
Aja9tochin
September 05, 2025
Technology
3
340
DDD集約とサービスコンテキスト境界との関係性
Aja9tochin
September 05, 2025
Tweet
Share
More Decks by Aja9tochin
See All by Aja9tochin
コレオグラフィ型サーガでのデータモデルの持ち方
pandayumi
0
13
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
360
業務改善原則を使った企画の重要性
pandayumi
0
29
セキュリティ視点以外の重要な脅威分析
pandayumi
0
14
脅威モデリングによるシフトレフト活動
pandayumi
0
8
ビジネスアーキテクチャにおける脅威分析
pandayumi
0
11
既存の脅威モデリング実施における新たな脅威とその対策に必要な思考
pandayumi
0
7
ADR運用におけるデータ利活用の考え方
pandayumi
0
380
Other Decks in Technology
See All in Technology
QA業務を変える(!?)AIを併用した不具合分析の実践
ma2ri
0
150
オブザーバビリティと育てた ID管理・認証認可基盤の歩み / The Journey of an ID Management, Authentication, and Authorization Platform Nurtured with Observability
kaminashi
1
720
入院医療費算定業務をAIで支援する:包括医療費支払い制度とDPCコーディング (公開版)
hagino3000
0
110
[VPoE Global Summit] サービスレベル目標による信頼性への投資最適化
satos
0
250
プロファイルとAIエージェントによる効率的なデバッグ / Effective debugging with profiler and AI assistant
ymotongpoo
1
210
AI駆動で進める依存ライブラリ更新 ─ Vue プロジェクトの品質向上と開発スピード改善の実践録
sayn0
1
320
パフォーマンスチューニングのために普段からできること/Performance Tuning: Daily Practices
fujiwara3
2
130
クラウドとリアルの融合により、製造業はどう変わるのか?〜クラスメソッドの製造業への取組と共に〜
hamadakoji
0
430
Implementing and Evaluating a High-Level Language with WasmGC and the Wasm Component Model: Scala’s Case
tanishiking
0
180
20251024_TROCCO/COMETAアップデート紹介といくつかデモもやります!_#p_UG 東京:データ活用が進む組織の作り方
soysoysoyb
0
110
SOTA競争から人間を超える画像認識へ
shinya7y
0
550
現場の壁を乗り越えて、 「計装注入」が拓く オブザーバビリティ / Beyond the Field Barriers: Instrumentation Injection and the Future of Observability
aoto
PRO
1
610
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Automating Front-end Workflow
addyosmani
1371
200k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
GitHub's CSS Performance
jonrohan
1032
470k
Practical Orchestrator
shlominoach
190
11k
Music & Morning Musume
bryan
46
6.9k
Optimizing for Happiness
mojombo
379
70k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.7k
Optimising Largest Contentful Paint
csswizardry
37
3.5k
The Cult of Friendly URLs
andyhume
79
6.6k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
Documentation Writing (for coders)
carmenintech
75
5.1k
Transcript
集約とサービス境界 の関係性 役職:ビジネスアーキテクト 社名:ユミ 駆動(工藤 由美)
前提条件 誰向けなのか? マイクロサービス化を検討しているアプリケーションアーキテクト サービス境界位置の設計に四苦八苦しているアーキテクト ビジネスオペレーション設計しているPdM どうなってほしいのか? 多角化シーンに適用できるサービスコンテキスト境界の定義の基本思想を認知できている 2025/9/5
影響受けた参考文献(これでも一部) 2025/9/5
主論点(テーマ) サービスコンテキストの境界位置は、どのようにして決定されるべきか? よく見かけるNGパターンは、以下の2つ。 ACID集約(強い整合性)範囲で区切ってしまうやり方 特定のシーンのみで最適化された分割の仕方 2025/9/5
自己紹介? 今回不要なので、すっ飛ばします。 目的に沿ってない 不要プロセスを排除=ECRSのE これぞアジャイル。 2025/9/5
サービス境界 ≠集約境界 • ACID特性について • 誤解を招かないための前提 • 2カテゴリー • なぜ境界範囲が一致しないのか
• How • 結論 2025/9/5
ACID特性とBASE特性 モノリシックアーキテクチャおよびまだ、蜜結合状態の マイクロサービス(例:エピックサーガ、伝言ゲームサー ガ)で満たせる品質特性。 雑に言うと、関連するデータがすべて更新されてるか されてないか?のどっちかしかない。 疎結合なマイクロサービスでは、BASEが基本。 ACIDでなく、時間経過で整合性取れればOK(即時 整合性よりも、可用性優勢) 自前で整合する処理をアプリに定義する必要
2025/9/5
誤解を招かないように前提 ※確かにACID集約の範囲は、サービス境界の判断の土台となる。 そのため、右図のような サービス境界がACID境界を分断するような 設計は絶対にあってはならない。 データの不整合リスク(データライフサイクル矛盾) サービス同士の静的な蜜結合状態 などによって、分散モノリスになってしまう。 2025/9/5
大きく2カテゴリーに分類される 2025/9/5
なぜこのようになるのか? 2025/9/5
非機能的な動機がコンポーネント 粒度を大きくする ネットワークを介して繋がるので、絶対にレイテンシーがある。それはUX低下を招く可能性。 攻撃対象が増えるので、セキュリティコストがかさむ 両集約へのセキュリティ要件は一緒でいい。 セキュリティ機能のDRYに反する可能性あるし、分けたくない。 他と同期通信で繋がってる テーブルの所有権を片方に割り当てられない アーキテクチャテスト、適応度関数がない これらの動機が、1つのサービスコンポーネント内に、
複数のACID集約を含む要因。 2025/9/5
レーダーチャートで境界位置の評価 事前条件: ACID集約境界の範囲を特定済であること 適応度関数(アーキテクチャテスト)があること ※複数ある評価軸は、すべてが同じ重みではない。 で、以下のように期待値計算する。 総合評価スコア=0.4×3+0.2×2.5+0.3×(-3)+~ ①
分割を促進させる動機となる品質軸と、分割しない方が良いという 動機となる品質軸を図のように色で表現。 ② 分割しない方が良いというものをマイナスで表現。 完了条件:スコアリング完了後、ADR書かれてること 2025/9/5
結論)論理境界≠物理境界 よって、ACID集約境界という論理境界と、 サービス境界という物理境界は、必ずしも一致しない。 サービスコンポーネント内のモジュールという単位で、 ACID集約境界を表現すること推奨。 2025/9/5
その境界位置は、 他の環境下でも 対応できるか? 2025/9/5
内・外部環境&制約で境界を考察 設計を考える際に、 エンドユーザーが利用するのはどのようなシーンか? 法律含めた外部環境は? 今の組織体制は? スキルレベルは? といった、前提&制約によって、サービス境界が決まる。 それですぐ境界位置設計しちゃいますか? 他のシーンでも、その境界が妥当と言えますか? 2025/9/5
環境が変われば境界位置も変化しうる 一度境界を定義しても、すぐに分割してはダメ。 境界位置が他のシーンで適さない場合、最悪、分散 化したのに、可用性が低下ということになりうる。 モデル上で分割したら、 それは、どのようなシーン(環境下)で妥当な境目? 他のシーンでも適切だろうか? と問うてみましょう。 2025/9/5
置かれたシーンとサービス境界の関係性 ビジネスは、大きく分けて、平常時と非常時があります。 平常時と非常時では、アーキテクチャに求められる特性が全然変わります。 平常時では、耐障害性>>回復性で、システムダウンしにくいという特性が優勢。 非常時には、耐障害性<<回復性。 事業継続のため、いかに素早い復旧が求められる。 ゆえに、片方での境界が もう片方でも妥当とは言えない。 2025/9/5
定性判断に役立つマトリクス ここまでをパターン化したら、右図のように考えると、 決定が手早くなる。 第1象限: 平常時も非常時でも同じとこで切り分けなので分割する。 第2象限: 平常時では分割だが、非常時では分けないので、分割しない。 第3象限: 平常時では分けないが、非常時では分ける最難関トレードオフ。 ここのために、新しい考えが必要。(後で触れます)
第4象限: 平常時でも非常時でも分けないので、絶対に分けない。 2025/9/5
サービス境界によって起きる別の問題 しかし、まだサービス境界には、以下の問題がある。 境界がないとまずい理由 境界がないと、データの整合性の担保が管理しにくい 組織の責任範囲が定義できない 境界があることで起きる他の問題:技術的制約を強く受けてしまう 一度定義したサービス境界位置が変えにくいため、ビジネスモデルがその制約を受ける 必死こいてサービスに分割したのに、環境変化でどの境界位置が変わらないとビジネス環境に適合しないということに 2025/9/5
Dynamic Consistency Boundary(DCB) 一時的にアトミック整合にしたい 整合性の境界範囲を後から拡大したい などという時に、 あとから動的に整合性レベルを変える シーンに応じて整合性の範囲を変える などが可能な設計手法。 詳しくは、これを読んどくれ→動的な整合性境界の設計
#マイクロサービス – Qiita または、イベントソーシング・CQRSイベントで触れられています。 (※もちろん、銀の弾丸ではない!! めっちゃ難易度高い。) 2025/9/5
静的vs動的?どちらを選定すべき? ・静的な整合性境界(ACID、BASE) ビジネスプロセスが安定的で、トランザクション の範囲が明確に決まっている場合はこっち! (こっちでも十分難易度高い ) ・動的な整合性境界 ビジネスプロセスがシナリオによって大きく変動 する場合。(例: 通常注文
vs. 高額注文) インシデント対応など、システムの動作モードを 動的に切り替えたい場合。 2025/9/5
限定的にDCBを採用 & 段階的移行せよ 定性的に描いた右図の部分 業務が複雑 差別化領域 環境により、境界位置が不安定 この条件が揃った箇所に対してのみDCB を限定的に採用する。 ※ただし、いきなりDCB適用は危険。
(アーキテクチャ可逆性が低い&あまりに もYAGNI違反) よって、段階的移行を強く推奨!! 2025/9/5 (詳細は、Qiitaを参照)
今日のまとめ ACID集約の範囲≠サービス境界 ① まずはACID集約の範囲探しましょう ② その上で、複数の品質特性で多角評価 ③ 分割しない方が良い時には、サービスコン ポーネント内のモジュールという単位で ACID集約の範囲を表現する
その切り分ける境界は多角化できている? ① 一度定義した境界が他シーンでも妥当かチェック ② シーンによって、不安定なコアサービスの境界には、 必要に応じて、DCBを検討する ③ 段階的に静的整合性 DCBへ移行 2025/9/5
今後の展望 集約には レベル0:ACID レベル1:強い結果整合性 レベル2:弱い結果整合性 レベル3:超弱い整合性 超大規模では、レベル3が登場します。 2025/9/5
大吉祥寺.pm こちらでカオスエンジニアリング について、5分でLTします。 今日の内容とも密接に関わります。 つか、マイクロサービスには、カオスエンジニアリングは 避けては通れない分野。 2025/9/5