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
310
DDD集約とサービスコンテキスト境界との関係性
Aja9tochin
September 05, 2025
Tweet
Share
More Decks by Aja9tochin
See All by Aja9tochin
コレオグラフィ型サーガでのデータモデルの持ち方
pandayumi
0
7
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
310
業務改善原則を使った企画の重要性
pandayumi
0
27
セキュリティ視点以外の重要な脅威分析
pandayumi
0
12
脅威モデリングによるシフトレフト活動
pandayumi
0
8
ビジネスアーキテクチャにおける脅威分析
pandayumi
0
11
既存の脅威モデリング実施における新たな脅威とその対策に必要な思考
pandayumi
0
4
ADR運用におけるデータ利活用の考え方
pandayumi
0
350
Other Decks in Technology
See All in Technology
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
120
自作LLM Native GORM Pluginで実現する AI Agentバックテスト基盤構築
po3rin
2
210
AI Agentと MCP Serverで実現する iOSアプリの 自動テスト作成の効率化
spiderplus_cb
0
270
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
100
AIが書いたコードをAIが検証する!自律的なモバイルアプリ開発の実現
henteko
1
230
“2件同時配達”の開発舞台裏 〜出前館PMが挑んだダブルピック実現に向けた体験設計〜
demaecan
0
160
Pure Goで体験するWasmの未来
askua
1
150
Deep Research と NotebookLM を使い倒す!レガシーリプレイスの技術選定と学習コスト削減術
tet0h
0
2.8k
あなたのWebサービスはAIに自動テストしてもらえる?アクセシビリティツリーで読み解く、AIの『視点』
yusukeiwaki
1
3.3k
analysis パッケージの仕組みの上でMulti linter with configを実現する / Go Conference 2025
k1low
1
240
いまさら聞けない ABテスト入門
skmr2348
0
170
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
49
14k
The Cost Of JavaScript in 2023
addyosmani
53
9k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
358
30k
BBQ
matthewcrist
89
9.8k
Agile that works and the tools we love
rasmusluckow
330
21k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Faster Mobile Websites
deanohume
310
31k
Speed Design
sergeychernyshev
32
1.1k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Embracing the Ebb and Flow
colly
88
4.8k
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