DDD集約とサービスコンテキスト境界との関係性

Transcript

1. 集約とサービス境界 の関係性 役職:ビジネスアーキテクト 社名:ユミ 駆動(工藤 由美)
2. 前提条件 誰向けなのか? マイクロサービス化を検討しているアプリケーションアーキテクト サービス境界位置の設計に四苦八苦しているアーキテクト ビジネスオペレーション設計しているPdM どうなってほしいのか? 多角化シーンに適用できるサービスコンテキスト境界の定義の基本思想を認知できている 2025/9/5
3. 影響受けた参考文献(これでも一部) 2025/9/5
4. 主論点(テーマ) サービスコンテキストの境界位置は、どのようにして決定されるべきか? よく見かけるNGパターンは、以下の２つ。 ACID集約(強い整合性)範囲で区切ってしまうやり方 特定のシーンのみで最適化された分割の仕方 2025/9/5
5. 自己紹介？ 今回不要なので、すっ飛ばします。 目的に沿ってない 不要プロセスを排除＝ECRSのE これぞアジャイル。 2025/9/5
6. サービス境界 ≠集約境界 • ACID特性について • 誤解を招かないための前提 • ２カテゴリー • なぜ境界範囲が一致しないのか • How • 結論 2025/9/5
7. ACID特性とBASE特性 モノリシックアーキテクチャおよびまだ、蜜結合状態の マイクロサービス(例:エピックサーガ、伝言ゲームサー ガ)で満たせる品質特性。 雑に言うと、関連するデータがすべて更新されてるか されてないか?のどっちかしかない。 疎結合なマイクロサービスでは、BASEが基本。 ACIDでなく、時間経過で整合性取れればOK（即時 整合性よりも、可用性優勢） 自前で整合する処理をアプリに定義する必要 2025/9/5
8. 誤解を招かないように前提 ※確かにACID集約の範囲は、サービス境界の判断の土台となる。 そのため、右図のような サービス境界がACID境界を分断するような 設計は絶対にあってはならない。 データの不整合リスク(データライフサイクル矛盾) サービス同士の静的な蜜結合状態 などによって、分散モノリスになってしまう。 2025/9/5
9. 大きく２カテゴリーに分類される 2025/9/5
10. なぜこのようになるのか？ 2025/9/5
11. 非機能的な動機がコンポーネント 粒度を大きくする ネットワークを介して繋がるので、絶対にレイテンシーがある。それはUX低下を招く可能性。 攻撃対象が増えるので、セキュリティコストがかさむ 両集約へのセキュリティ要件は一緒でいい。 セキュリティ機能のDRYに反する可能性あるし、分けたくない。 他と同期通信で繋がってる テーブルの所有権を片方に割り当てられない アーキテクチャテスト、適応度関数がない これらの動機が、１つのサービスコンポーネント内に、 複数のACID集約を含む要因。 2025/9/5
12. レーダーチャートで境界位置の評価 事前条件:  ACID集約境界の範囲を特定済であること  適応度関数(アーキテクチャテスト)があること ※複数ある評価軸は、すべてが同じ重みではない。 で、以下のように期待値計算する。 総合評価スコア＝0.4×3+0.2×2.5+0.3×(-3)+～ ① 分割を促進させる動機となる品質軸と、分割しない方が良いという 動機となる品質軸を図のように色で表現。 ② 分割しない方が良いというものをマイナスで表現。 完了条件:スコアリング完了後、ADR書かれてること 2025/9/5
13. 結論）論理境界≠物理境界 よって、ACID集約境界という論理境界と、 サービス境界という物理境界は、必ずしも一致しない。 サービスコンポーネント内のモジュールという単位で、 ACID集約境界を表現すること推奨。 2025/9/5
14. その境界位置は、 他の環境下でも 対応できるか？ 2025/9/5
15. 内・外部環境＆制約で境界を考察 設計を考える際に、 エンドユーザーが利用するのはどのようなシーンか? 法律含めた外部環境は? 今の組織体制は? スキルレベルは? といった、前提＆制約によって、サービス境界が決まる。 それですぐ境界位置設計しちゃいますか? 他のシーンでも、その境界が妥当と言えますか? 2025/9/5
16. 環境が変われば境界位置も変化しうる 一度境界を定義しても、すぐに分割してはダメ。 境界位置が他のシーンで適さない場合、最悪、分散 化したのに、可用性が低下ということになりうる。 モデル上で分割したら、 それは、どのようなシーン(環境下)で妥当な境目? 他のシーンでも適切だろうか? と問うてみましょう。 2025/9/5
17. 置かれたシーンとサービス境界の関係性 ビジネスは、大きく分けて、平常時と非常時があります。 平常時と非常時では、アーキテクチャに求められる特性が全然変わります。 平常時では、耐障害性＞＞回復性で、システムダウンしにくいという特性が優勢。 非常時には、耐障害性＜＜回復性。 事業継続のため、いかに素早い復旧が求められる。 ゆえに、片方での境界が もう片方でも妥当とは言えない。 2025/9/5
18. 定性判断に役立つマトリクス ここまでをパターン化したら、右図のように考えると、 決定が手早くなる。 第１象限: 平常時も非常時でも同じとこで切り分けなので分割する。 第２象限: 平常時では分割だが、非常時では分けないので、分割しない。 第３象限: 平常時では分けないが、非常時では分ける最難関トレードオフ。 ここのために、新しい考えが必要。(後で触れます) 第４象限: 平常時でも非常時でも分けないので、絶対に分けない。 2025/9/5
19. サービス境界によって起きる別の問題 しかし、まだサービス境界には、以下の問題がある。 境界がないとまずい理由 境界がないと、データの整合性の担保が管理しにくい 組織の責任範囲が定義できない 境界があることで起きる他の問題:技術的制約を強く受けてしまう 一度定義したサービス境界位置が変えにくいため、ビジネスモデルがその制約を受ける 必死こいてサービスに分割したのに、環境変化でどの境界位置が変わらないとビジネス環境に適合しないということに 2025/9/5
20. Dynamic Consistency Boundary(DCB) 一時的にアトミック整合にしたい 整合性の境界範囲を後から拡大したい などという時に、 あとから動的に整合性レベルを変える シーンに応じて整合性の範囲を変える などが可能な設計手法。 詳しくは、これを読んどくれ→動的な整合性境界の設計 #マイクロサービス – Qiita または、イベントソーシング・CQRSイベントで触れられています。 （※もちろん、銀の弾丸ではない!! めっちゃ難易度高い。） 2025/9/5
21. 静的vs動的？どちらを選定すべき？ ・静的な整合性境界(ACID、BASE) ビジネスプロセスが安定的で、トランザクション の範囲が明確に決まっている場合はこっち! (こっちでも十分難易度高い ) ・動的な整合性境界 ビジネスプロセスがシナリオによって大きく変動 する場合。（例: 通常注文 vs. 高額注文） インシデント対応など、システムの動作モードを 動的に切り替えたい場合。 2025/9/5
22. 限定的にDCBを採用 & 段階的移行せよ 定性的に描いた右図の部分 業務が複雑 差別化領域 環境により、境界位置が不安定 この条件が揃った箇所に対してのみDCB を限定的に採用する。 ※ただし、いきなりDCB適用は危険。 (アーキテクチャ可逆性が低い&あまりに もYAGNI違反) よって、段階的移行を強く推奨!! 2025/9/5 (詳細は、Qiitaを参照)
23. 今日のまとめ ACID集約の範囲≠サービス境界 ① まずはACID集約の範囲探しましょう ② その上で、複数の品質特性で多角評価 ③ 分割しない方が良い時には、サービスコン ポーネント内のモジュールという単位で ACID集約の範囲を表現する その切り分ける境界は多角化できている? ① 一度定義した境界が他シーンでも妥当かチェック ② シーンによって、不安定なコアサービスの境界には、 必要に応じて、DCBを検討する ③ 段階的に静的整合性 DCBへ移行 2025/9/5
24. 今後の展望 集約には レベル0:ACID レベル1:強い結果整合性 レベル2:弱い結果整合性 レベル3:超弱い整合性 超大規模では、レベル3が登場します。 2025/9/5
25. 大吉祥寺.pm こちらでカオスエンジニアリング について、5分でLTします。 今日の内容とも密接に関わります。 つか、マイクロサービスには、カオスエンジニアリングは 避けては通れない分野。 2025/9/5