背景
静的な整合性境界へのジレンマ
ACIDの強い集約の境界も、マイクロサービスの文脈の結果整合性の境界も、
一度定義してしまったら、もうその静的な整合性境界に縛られてしまい、
他の前提シーンでその境界位置があまり適切ではないとなった場合に、
無理やり以下のようにACID境界の範囲を拡大させるなどの緊急的な対処療法で太刀打ちしていた。
ただしそうすると、
強い集約内の状態更新に時間がさらにかかる。
データの所有権が曖昧になる
という致命的なUX低下の問題を招いてしまい困っていました。
静的な整合性境界の課題に対する解決策
静的な整合性境界が、ある状況下では最適でも、別の状況下（たとえば緊急時など含む例外時）では不適切になるという問題は、分散システムにおける大きな課題です。
この「静的な境界」の課題を解決し、実行時にその範囲を動的に変えるための設計手法は一応存在します。
それは、ワークフローエンジンや動的なルーティングを活用して、ビジネスプロセス自体の「構成（コンポジション）」を動的に変えるアプローチです。
整合性境界を動的に変える設計手法
1. ワークフローエンジンによる動的なオーケストレーション
概要
Temporal, Camunda, AWS Step Functionsのようなワークフローエンジンを使い、一連のビジネスプロセスを「ワークフロー」として定義します。個々のマイクロサービスは、そのワークフローを構成する「ステップ」として機能します。
動的な境界変更
このアプローチの強力な点は、実行するビジネスシナリオに応じて、呼び出すワークフローの定義自体を変えられることです。
シナリオA（通常注文）
「注文受付」→「決済」
というシンプルなワークフローを実行。
この時の整合性境界は、この2つのサービスに限定されます。
シナリオB（高額な初回注文）
「注文受付」→ 「不正検知」→「信用情報確認」→「決済」→「特別在庫引当」
という、より多くのサービスを巻き込んだ複雑なワークフローを実行します。
このように、ワークフローの定義を複数用意し、条件に応じて使い分けることで、一時的に強く連携し、整合性を担保すべきサービスの範囲（境界）を動的に変更していることになります。
2. フィーチャーフラグによる整合性レベルの動的変更
概要
フィーチャーフラグ（機能フラグ）を使い、コードのロジックをリアルタイムで切り替えることで、整合性の取り方を動的に変更します。
動的な境界変更
アプリケーションのコード内で、ビジネスルールの条件分岐をフィーチャーフラグによって制御します。
// 例: 高額注文の場合のみ、在庫サービスと強く連携する
public void placeOrder(Order order) {
orderService.save(order);
// Feature Flagで動的に境界を広げるか判断
if (featureFlags.isEnabled("strong-inventory-check", order.getCustomerId())) {
// 在庫サービスを直接呼び出し、即時整合性を確保（境界を拡張）
inventoryService.reserveStock(order.getItems());
}
// それ以外の場合は、イベントを発行して結果整合性で在庫を処理
eventPublisher.publish(new OrderPlacedEvent(order));
}
この例では、フィーチャーフラグのON/OFFによって、整合性境界が「注文サービス単体」から「注文サービス＋在庫サービス」へと動的に変化します。
ここまでの結論
これらの先進的な手法に共通する思想は、サービス間の連携ロジックを
「ハードコーディングされた静的な依存関係」から、「外部から注入・変更可能な、動的なプロセス定義」へと分離することです。
これにより、アーキテクチャの整合性境界は、固定された制約ではなく、ビジネスの変化に俊敏に対応できる、柔軟な設計要素となります。
静的な境界 vs. 動的な境界：適材適所の使い分け
以前のこの記事で触れたような、第3象限のような
平常時とインシデント対応中で求められる整合性の範囲が異なる
という状況は、まさに動的な整合性境界が最も輝くユースケースの一つです。
インシデント発生時には、早期復旧のために一部のサービスを切り離しつつも、主要な機能の整合性は普段以上に強く保証したい、といった要求が生まれます。
上記の動的な整合性境界の手法は、このような状況に応じたアーキテクチャの適応を可能にしてくれます。
では、従来の静的な整合性境界と、この動的な整合性境界の手法、
どちらがどんな時により適していると言えるのでしょうか？
少なくとも、どちらか一方が絶対的に優れているわけではありません。
それぞれに適した場面があり、成熟したアーキテクチャは両者を使い分けます。
静的な整合性境界
一度定義したサービスの境界（＝整合性境界）を変更しない、伝統的で一般的なアプローチです。
変更がほぼないようなサービス境界に対して、上記の動的にその範囲を変えるような設計手法はどう考えてもオーバーエンジニアリングです。
その境界が提供する、対象のビジネスユースケースの変更頻度や、
変更時の他のサービス境界への影響度合いなどをRDRAモデルなどでモニタリングして、
どの程度安定しているのか？ 変更された際のインパクトを判断しましょう。
最適なケース
・ビジネスプロセスが安定的で、トランザクションの範囲が明確に決まっている場合。
・システムのシンプルさや予測可能性が、柔軟性よりも重視される場合。
（例：ユーザー登録、商品カタログ管理など、責務が明確なほとんどのサービス）
メリットとデメリット
動的な整合性境界
上記で触れたように、ワークフローエンジンなどを使い、実行時の状況に応じて、整合性を担保するサービスの範囲を動的に変更するアプローチです。
最適なケース
・ビジネスプロセスがシナリオによって大きく変動する場合。（例: 通常注文 vs. 高額注文）
・インシデント対応など、システムの動作モードを動的に切り替えたい場合。
・新しいビジネス要件に対し、サービスを再デプロイすることなく、迅速に連携パターンを変更したい場合。
メリットとデメリット
通常の結果整合性の境界の運用でさえも、なかなか難しいのに、さらに複雑化するのは
結構辛いですね。
しかも、それによって新たな脆弱さが生まれては意味がないです。
ここまでのまとめ
基本は 「静的な整合性境界」 でシンプルに設計し、システムの大部分を予測可能に保つべきです。
そして、ビジネスの中核をなすような、特に変動が激しく、多様なシナリオへの対応が求められるごく一部の重要なプロセスに対してのみ、「動的な整合性境界」という強力な武器を選択的に適用するのが、最も現実的で効果的なアプローチと言えるでしょうな。
【ドメイン駆動設計をはじめよう】の文脈の言葉で言うならば、
この図のコアドメイン領域が、その対象スコープですね！！
逆にそれ以外の一般領域とかは、静的なコンテキスト境界のままにしておきましょう。
動的なBASE特性境界の設計にも使える
さて、上では詳細に整合性と行っても、アトミックな強い集約境界なのか、
それとも結果整合性の境界位置を動的に変えられるのか？を深く突っ込んで触れられなかったので、ここのトピックで詳細に踏み込みます。
先に結論から話すと、
動的な整合性境界の考え方は、一時的に強い集約（アトミック性）を作り出すだけでなく、
「どのサービスが、どのイベントの影響を受けて、最終的に整合性を取るべきか」という、
「結果整合性の境界」を動的に定義する
ためにも使えます。
なので、デメリットの側面を考えなければ、本当に境界位置を動的に後から変えられて、
しかもその整合レベルをアトミックでも結果整合でもできるのは本当に便利です。
動的な結果整合性境界とは
静的なイベント駆動アーキテクチャでは、どのサービスがどのイベントを購読（サブスクライブ）するかは、比較的固定されてしまいます。
これに対し、動的なアプローチでは、実行時のコンテキストやビジネスルールに応じて、
イベントを通知する範囲や、影響を受けるサービスの集合を柔軟に変更します。
1. ワークフローによるイベント発行先の動的変更
ワークフローエンジンを使い、ビジネスシナリオに応じて発行するイベントの種類や宛先を動的に変えることで、結果整合性の境界を制御します。
設計の考え方
これは、ビジネスプロセス（＝整合性を担保すべき一連の流れ）の定義を、個々のサービスから完全に分離・外部化する設計思想です。
個々のマイクロサービスは、単機能な「ワーカー」に徹します（例：「決済を実行する」「在庫を確保する」）。
どのワーカーを、どの順番で、どの条件で呼び出すかというオーケストレーターの役割を、
ワークフローエンジン（Temporal, AWS Step Functionsなど）が担います。
ビジネスシナリオごとに異なるワークフローを定義しておくことで、整合性境界を動的に変更できます。
以下では、具体的な設計例として、
注文サービス、決済サービス、在庫サービス、不正検知サービス からなるECサイトの注文処理を考えてみましょう。
A) ACID特性に近い、強い整合性境界を動的に作るケース
・シナリオ
法人向けの高額な初回注文など、絶対に売越しや不正を許容できないクリティカルな操作。
・ワークフロー定義 (HighValueOrderWorkflow)
-
不正検知サービスを同期的に呼び出し、結果を待つ
-
在庫サービスを同期的に呼び出し、在庫を 仮確保（ロック） する
-
決済サービスを同期的に呼び出し、与信枠を確保する
-
全て成功したら、各サービスに本実行（Confirm） を指示。
一つでも失敗したら、補償トランザクション（Cancel） を呼び出し、全てを元に戻す（在庫の解放など）。
・効果
このワークフローが実行されている間、
複数のサービスをまたがる一時的なACID特性（アトミックな整合性） が、ワークフローエンジンによって動的に作り出されます。
B) 結果整合性（BASE）の境界を動的に定義するケース
・シナリオ
通常の個人ユーザーによる低額な注文。多少の在庫変動リスクよりも、ユーザー体験（レスポンス速度）を優先。
・ワークフロー定義 (StandardOrderWorkflow)
注文サービスを呼び出し、注文を受け付けた時点で、即座にユーザーに応答を返す。
注文サービスが発行した 「注文が作成された」 イベントをトリガーに、
後続の処理（決済、在庫引き当て）は非同期で実行する。
・効果
この場合、強い整合性境界は注文サービス内に留まります。
後続の決済サービスや在庫サービスは、結果整合性の境界に動的に含まれます。
他の動的結果整合境界の事例
シナリオA（通常注文）
ワークフローは「注文が作成された」イベントのみを発行します。
この場合、結果整合性の境界は、注文サービスと、このイベントを購読する基本的なサービス（例: 倉庫サービス）に限定されます。
シナリオB（ギフトカードを使った注文）
ワークフローは「注文が作成された」イベントに加えて、「ギフトカードが使用された」という別のイベントを発行します。
これにより、このトランザクションに限り、ギフトカードサービスも結果整合性の境界に動的に含まれることになります。
2. フィーチャーフラグによるイベント発行の制御
フィーチャーフラグを使い、新しいシステムへのデータ連携を段階的に行います。
設計の考え方
これは、単一のサービス内に複数の整合性パターンを実装しておき、外部のフラグ設定によって、実行時にどのパターンを使用するかを切り替える設計思想です。
フィーチャーフラグは、コードの中の動的な if/elseスイッチ として機能します。
このスイッチのON/OFFは、管理画面などからリアルタイムで変更できます。
これにより、サービスを再デプロイすることなく、その振る舞い（＝整合性境界）を動的に変更できます。
具体的な設計例として、
注文サービスが、在庫サービスとどう連携するかという、在庫確認のロジック を考えてみましょう。
A) ACID特性に近い、強い整合性境界を動的に作るケース
・シナリオ
限定セール品など、リアルタイムの在庫数が非常に重要な商品の注文。
・実装
// 注文サービス内のコード
if (featureFlags.isEnabled("realtime-stock-check", order.getProductId())) {
// フラグがONの場合: 在庫サービスを同期的（APIコール）に呼び出す
inventoryService.reserveStock(order.getItems());
} else {
// フラグがOFFの場合: イベントを発行して非同期に処理
eventPublisher.publish(new OrderPlacedEvent(order));
}
・効果
限定セール品のプロダクトIDに対してフィーチャーフラグをONにすることで、その注文処理の間だけ、整合性境界が注文サービス＋在庫サービスへと動的に拡張されます。
B) 結果整合性（BASE）の境界を動的に定義するケース
・シナリオ
インシデント対応。 在庫サービスに障害が発生し、応答が非常に遅くなっている。
・実装
上記と同じコードを利用します。
// 注文サービス内のコード
if (featureFlags.isEnabled("realtime-stock-check", order.getProductId())) {
// フラグがONの場合: 在庫サービスを同期的（APIコール）に呼び出す
inventoryService.reserveStock(order.getItems());
} else {
// フラグがOFFの場合: イベントを発行して非同期に処理
eventPublisher.publish(new OrderPlacedEvent(order));
}
・効果
運用者が管理画面から、在庫確認のフィーチャーフラグを緊急でOFFにします。
すると、全ての注文は、在庫サービスを同期的に呼び出すことなく、イベント発行（結果整合性）のルートを通るようになります。
これにより、在庫サービスの障害が注文サービスへ波及することを防ぎ、システム全体の可用性を維持するために、整合性境界を動的に縮小させています。
他の事例
・シナリオ
新しい分析サービスを導入するケース。
・設計
既存の注文サービスに、フィーチャーフラグで制御されるロジックを追加します。
// 注文処理...
eventPublisher.publish(new OrderPlacedEvent(order));
// Feature FlagがONの場合のみ、新しい分析サービス向けのイベントを発行
if (featureFlags.isEnabled("send-to-new-analytics-service")) {
eventPublisher.publish(new OrderAnalyticsEvent(order));
}
・効果
最初はフラグをOFFにしておき、新しい分析サービスを安全にデプロイします。
その後、徐々にフラグをONにしていくことで、システムの挙動をリアルタイムで変更し、
結果整合性の境界を動的に拡張していくことができます。
ここまでの振り返り
同じサービスAとサービスBの組み合わせであっても、実行されるビジネスシーンに応じて、
両者を囲む整合性境界を「結果整合性」にしたり、「アトミック（強い整合性）」にしたりすることができるということです。
商品カタログサービスと在庫サービスからなる、ECサイトの商品在庫表示という事例で
あたらめて図解で表現してみましょう。
①. ユーザーが商品を閲覧している（結果整合性が適しているケース）
状況
ユーザーが商品詳細ページをただ見ているだけです。
求められること
ページの表示速度が最優先。
在庫数が数秒〜数分前のものであっても、ビジネス上の問題はほとんどありません。
境界の定義
このシーンでは、商品カタログサービスと在庫サービスは疎に連携します。
ページ表示に必要な商品情報は先に返し、在庫数だけを非同期で取得・表示します。
両者を囲む境界は結果整合性です。
②. ユーザーが「最後の1点」をカートに入れる（アトミックな整合性が適しているケース）
状況
ユーザーが在庫残り1点の商品をカートに入れるという、クリティカルな操作を行いました。
求められること
売り越しを防ぐため、「在庫があることを確認し、その在庫を確保（仮押さえ）する」という一連の処理は、絶対に分割されてはいけません（アトミック性）。
境界の定義
このシーンでは、ワークフローエンジンなどが起動し、
商品カタログサービスと在庫サービスを同期的に呼び出し、処理がすべて成功するか、
すべて失敗するかのどちらかになることを保証します。
この瞬間、両者を囲む境界は一時的にアトミックになります。
ここまでの結論
この動的なアプローチは、従来の固定的な整合性境界の設計などでのしがらみをなくし、
システムアーキテクチャの進化可能性を劇的に高めてくれます。
新しいサービスや要件が追加されても、既存のサービスのコアロジックに手を加えることなく、ワークフローやフラグの変更だけで、柔軟に連携範囲（＝結果整合性の境界）を広げたり、狭めたりすることが可能です。
静的な境界から動的へ移行のステップ
正直、いきなり動的な境界の設計はムリゲーに近いかもしれません。
静的な境界の設計でさえも、耐障害性やら、パフォーマンスなどの複数の品質軸で評価し、
その効果、境界位置の妥当性を検証するなど、なかなかに大変です。
組織の学習度合いという現在のスキルレベルという制約を踏まえて、
最初は静的な境界の設計から入り、徐々に必要に応じて動的な境界設計という風に移行させた方が賢明でしょう。
実際、多くの場合、既存の静的な整合性境界から、動的な境界へと「進化」させるアプローチを取るそうです。
最初から全ての連携を動的に設計するのは、あまりにも過剰設計になりがちです。
ステップ1：静的な境界の明確化と、課題の特定
まず大前提として、サービス（コンポーネント）が静的な整合性境界として、適切に分離されている状態からスタートします。
その上で、「どのビジネスプロセスが、この静的な境界のせいで何かビジネスモデルが固定的になってしまっているなどの問題がないか？」を特定します。
課題の例
「通常注文と予約注文で、連携すべきサービス群が全く異なり、コードの分岐が複雑化している」
「インシデント発生時に、手動で特定の連携を止めたり、別の処理に切り替えたりするのが困難になっている」
ステップ2：プロセスロジックの外部化（ワークフローの導入）
ここが設計の核心です。
サービス間の連携や呼び出し順序といった
「プロセス（オーケストレーション）のロジック」を、個々のサービスから外部のワークフローエンジンに移管
します。
どういうことかというと、以下のような変化です。
Before
「注文サービス」が、自身のコード内で「もしAなら決済サービスを呼び、Bなら在庫サービスを呼ぶ」といった複雑なロジックをハードコーディングしている。
After
ワークフローエンジン (Temporal, AWS Step Functionsなど) が、「もしAなら…」というプロセスフローをワークフローとして定義する。
これで注文サービスは、このワークフローを開始するだけの、シンプルな役割になります。
この外部化されたワークフローの仕組みは、まさしくStrategyパターンの大規模（アーキテクチャレベル）な適用例と見なすことができます。
ステップ3：各サービスの「ワーカー」化
ワークフローエンジンから呼び出されるために、各サービスをよりシンプルで受け身な
「ワーカー」へとリファクタリングします。
責務
各サービスは、プロセス全体の流れを意識せず、自身のビジネスロジックを実行することだけに集中します。（例: 「決済を実行する」「在庫を確保する」）
インターフェース
ワークフローから呼び出されるための、シンプルで冪等性（べきとうせい）のあるAPIを公開します。（冪等性：同じリクエストを何度受けても、結果が同じになる性質）
通常の抽象化して、インターフェイスを具体な実装からボトムアップに設計するのとメカニズムは一緒です。
ステップ4：段階的な移行（ストラングラー・フィグ・パターン）
いきなり全てを新しい方式に切り替えるのはあまりに危険です。
ストラングラー・フィグ・パターンと呼ばれる手法で、段階的に移行しましょう。
発想は、ストラングラーパターンとまるっきり一緒です。
以下に、その手順を書いておきます。
①. 並行稼働
既存の静的な連携ロジックは残したまま、新しいワークフローエンジンを並行して稼働させます。
②. ルーティング
APIゲートウェイやプロキシを使い、最初は全てのリクエストを既存のロジックに流します。
③. 段階的切り替え
フィーチャーフラグなどを使い、まず「一部のユーザー」や「特定の注文タイプ」だけを、新しいワークフローに流します。
④. 検証
新しいワークフローが正しく、かつ期待通りに動作することを監視・検証します。
⑤. 完全移行
問題がないことを確認しながら、徐々に新しいワークフローへ流すリクエストの割合を増やしていき、最終的に100%にします。
⑥. 古いロジックの削除
既存のロジックが不要になったら、安全に削除します。
この時、カオス実験も行っておくと、さらに自信をもって移行できると思います。
このように段階的ステップを踏むことで、稼働中のシステムを止めることなく、安全に静的な整合性境界から、より柔軟な動的な整合性境界へとアーキテクチャを進化させることができます。
ちなみにこの設計思想、CQRSの組み立ての際にも、
アトミックから結果整合にする際にも使ったあの設計移行計画の思想です。
データ所有権の割り当て
では、動的な整合境界の変化に伴い、データの所有権はどうなるのでしょうか？
ココが頭を悩ませるポイントです。
基本的なデータの所有権ルールは、通常の場合と同じで、変えるべきではありません。
その代わりに、サービス間の連携方法（プロトコル）を、より洗練された「一時的な権限委譲」のメカニズムで設計する必要があります。
なぜ「データの所有権」は変えてはいけないのか？
大前提として、「どのデータが、どのサービスの管理下にあるか」という所有権のルールは、常に静的で明確でなければなりません。注文サービスが注文データベースの唯一の所有者である、という原則は不変です。
ワークフローエンジンや他のサービスが、これらのデータを直接書き換えることは絶対にNGです。
もし、この所有権が動的に変わってしまうと、
・どの情報が信頼できる「正」なのか？
・データの不整合が起きた際、どちらのサービスに責任があるのか？
・誰がデータのバックアップや復元を行うのか？
といった基本的な管理が不可能になり、システム全体が崩壊します。
「所有権」と「トランザクション制御権」の分離
ここが重要な点です。
動的な整合性境界の設計では、
データの所有権と、そのデータを変更する
一連のプロセスを管理する「トランザクションの制御権」 を明確に分離します。
動的なアトミック整合性が求められるシーンでは、参加する各サービスは、トランザクションをコミット（確定）またはロールバック（取消）する権利を、一時的に外部のオーケストレーター（ワークフローエンジンなど）に委譲します。
データの所有者（各サービス）
・自身のデータに対する責任を持つ。
・外部からの指示に基づき、自身のデータを変更するためのAPI（例: 在庫を仮確保する, 在庫確保を確定する）を公開する。
トランザクションの制御者（ワークフローエンジンなど）
・データは一切所有しない。
・ビジネスプロセス全体の流れ（どのサービスのAPIを、どの順番で呼び出すか）を定義する。
・各サービスに対して「仮確保しろ」「本確定しろ」「取り消せ」といった指示を出す役割に徹します。
具体的な設計例：高額注文ワークフロー
1. ワークフロー開始
ワークフローエンジンが「高額注文プロセス」を開始します。
2. 在庫の仮確保
・ワークフローは、在庫サービスに対し「商品Aを10個、仮確保せよ」というAPIを呼び出します。
・在庫サービスは、自身の在庫データベースのステータスを「引当可能」から「仮確保中」に変更します。（書き込み権限は在庫サービスが持つ）
3. 決済の与信確保
・ワークフローは、決済サービスに対し「金額Y円の与信枠を確保せよ」というAPIを呼び出します。
・決済サービスは、自身の決済データベースのステータスを更新します。
4. 本実行または補償
・上記のステップが全て成功した場合、ワークフローは各サービスに「本実行（Confirm）」を指示します。各サービスは、自身のDBのステータスを「確定」に変更します。
・もし途中でいずれかのステップが失敗した場合、ワークフローはそれまでに成功したサービス全てに「取消（Cancel）」を指示（補償トランザクション）します。
このプロセスにおいて、データベースへの書き込みは、常にそのデータの所有者であるサービス自身が行っています。
ワークフローエンジンは、そのタイミングと順序を制御しているだけです。
TCCパターン
一時的に外部のオーケストレーター（ワークフローエンジンなど）に委譲するのは、
TCC (Try-Confirm/Cancel) というパターンでよく実装されます。
1. Try（仮実行・意思確認）フェーズ
オーケストレーターが、在庫サービスに「在庫を仮確保できますか？」と問い合わせます。
在庫サービスは、自身のDB内で在庫を「仮確保中」ステータスにし、
「準備OKです。最終判断はあなたに委ねます」とオーケストレーターに応答します。
この時点で制御権をオーケストレーターに委譲しています。
2. Confirm（確定）フェーズ:
オーケストレーターが、参加する全てのサービス（在庫、決済など）から「準備OK」の応答を受け取ったら、全員に「本実行してください」と指示を出します。
指示を受けた在庫サービスは、自身の判断でステータスを「仮確保中」から「確定」に変更します。
3. Cancel（取消）フェーズ:
もしTryフェーズで誰か一人が失敗した場合、オーケストレーターは、それまでに成功した全員に「取消してください」と指示を出します。
在庫サービスは、ステータスを「仮確保中」から「引当可能」に戻します。
書き込みはオーナーのみ
このプロセスにおいて、在庫DBへの書き込みは常に所有者である在庫サービスだけが行っています。
しかし、その書き込みを「最終的に確定させるか、取り消すかの判断（制御権）」は、
一時的にオーケストレーターが握っているのです。
つまり！！
動的な整合性境界の設計とは、データの所有権のルールを壊すのではなく、その所有者たちを協調させるための、より上位の制御メカニズムを追加するアプローチです。
静的境界では、データを所有する各サービスが自身の判断でデータを更新していましたが、
動的な境界では、
一時的にコミット/ロールバックの権利のみを、外部のワークフローに委譲する
と考えるとしっくりくるのではないでしょうか。
さいごのまとめ
このように、動的な整合性境界の設計とは、「ワンサイズ・フィットオール」の静的なルールを捨てることです。
ビジネス操作のコンテキスト（シーン）を理解し、そのリスクと要求に応じて、パフォーマンスを優先する「結果整合性」と、正確性を優先する「アトミックな整合性」を、同じサービス群に対して動的に使い分ける。それこそが、このアプローチの真髄です。
データの所有権ルールは、シンプルで静的なまま維持すべきです。
その上で、動的な整合性境界を実現するために、サービス間の連携プロトコルをより高度化し、「仮状態」の導入や、「制御権の一時的な委譲」といった洗練されたメカニズムを設計することが求められます。
今後の研究課題
最近の設計系のイベントで、DCBという設計思想も出てきました。
恐らくですが、動的な整合境界の設計には、イベントソーシングだけでなく、
この設計案も組み合わせて使うことが求められると感じています。
ここに関しては、まだ実務で扱ったことがないので、今後の研究課題としておきます。