エピローグ ── 一貫性の「新しい語彙」を手に入れる

このシリーズで学んだこと
Ch.2: 集約は「設計時に固定された一貫性の境界」
→ 単一エンティティの制約には最適
→ クロスエンティティの制約には Saga が必要(一時的不整合を許容)
Ch.3: DCB は「実行時に動的に決定される一貫性の境界」
→ 一貫性は構造ではなく条件
→ Consistency becomes a condition, not a structure
Ch.4: 技術的な仕組み
→ タグ付きイベント + 動的クエリ + 条件付き書き込み
→ 関連するイベントだけが競合(不要なシリアライゼーションの排除)
Ch.5: 実践ユースケース
→ 在庫予約、一意性制約、予算管理、ダブルブッキング防止、ワークフロー
→ 全てに共通: 判断の範囲と一貫性の範囲を一致させる
Ch.6: 集約との共存
→ 「どちらか」ではなく「どちらも」
→ 集約で足りる場面は集約、クロスカットする制約は DCB
DCB がもたらすパラダイムシフト
DCB の本質的な貢献は、一貫性に関する新しい語彙を提供したことだ。
Before DCB:
「強整合性」= 1つの集約内のトランザクション
「結果整合性」= 複数集約にまたがるもの全て
→ 中間がない。クロスエンティティの制約は全て「結果整合性」に押し込まれる
After DCB:
「強整合性」= 条件付き書き込みで保証される範囲(動的に決定)
「結果整合性」= 本当に結果整合性で十分な範囲
→ 「本当に結果整合性が必要なもの」と
「集約の境界設計の都合で結果整合性に追いやられていたもの」を区別できる
今後の動向
DCB はまだ若い概念だ(2023年提唱、2025年に仕様策定)。以下の動向に注目したい。
1. イベントストアのネイティブ対応
EventSourcingDB、UmaDB が先行。
EventStoreDB や Axon が対応するかは今後の展開次第。
2. フレームワークへの統合
Axon Framework(Java)、Marten(.NET)などの
主要イベントソーシングフレームワークが DCB パターンをサポートするか。
3. 実践事例の蓄積
2025年末の時点では、公開されている大規模な本番事例はまだ少ない。
Bastian Waidelich が言及したクライアント事例の詳細が公開されれば、
パターンの成熟が加速する。
4. CQRS との統合パターン
DCB はコマンドサイド(書き込み)の話。
クエリサイド(読み取り)の Projection との連携パターンの確立。
参考文献
一次情報
- dcb.events — Sara Pellegrini, Bastian Waidelich, Paul Grimshaw による DCB の公式サイト
- Kill Aggregate? An Interview on Dynamic Consistency Boundaries — Bastian Waidelich のインタビュー
- Dynamic Consistency Boundaries - EventSourcingDB — DCB の技術解説
- Rethinking microservices architecture through DCB - Axon IQ — マイクロサービスにおける DCB の解説
実装リファレンス
- bwaidelich/dcb-eventstore — DCB パターンのリファレンス実装(PHP)
- bwaidelich/dcb-example-courses — 講座予約の DCB 実装例
- umadb-io/umadb — DCB ネイティブ対応のイベントストア(Rust)
DDD 集約の基礎
- Domain-Driven Design — Eric Evans(2003)。集約の原典
- Implementing Domain-Driven Design — Vaughn Vernon(2013)。集約の設計ガイドライン
- DDD Aggregates: Consistency Boundary — James Hickey の集約解説
最後に
集約は DDD の偉大な発明だ。しかし「全ての一貫性の問題を集約で解決しなければならない」という教条主義は、実務でエンジニアを苦しめてきた。
DCB は、集約を否定するのではなく「集約では窮屈な場面に、別の選択肢を提供する」。その選択肢は「一貫性の境界を設計時に固定するのではなく、実行時に動的に決定する」というシンプルだが強力なアイデアだ。
集約と DCB の両方を道具箱に持つことで、ドメインモデリングの設計空間が広がる。それが、このシリーズを通じて伝えたかったことだ。