Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
DDD実践(ベスト)プラクティス{ドメインイベントとマイクロサービスと組織の関係}
加藤潤一(かとじゅん) ChatWork 2016/10/24
DDD実践ベストプラクティス
2016/3/26 © ChatWork All rights reserved.
自己紹介
•@j5ik2o •ChatWorkでテックリードをやっています。 •過去はSeasar2/Java、今はScala/Akkaが主戦場。 •最近は CQRS+ES, Akkaなどを使って仕事をしています。 •DDDで迷子になってたら声かけてください。アドバイスします。
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved.
アジェンダ•タイトル先行で考えた→書いているうちにベストなプラクティスじゃなくてもいいとなったので、ベストかどうかはさておきという前提で…。 • CQRSとは • CQRS + Event Sourcingとは • ドメインイベントとマイクロサービス • マイクロサービスとコンウェイの法則 • コンウェイの法則とDDDの関係性
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 4
開発者の方が多いと思うので 戦術の話から
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 5
ドメインイベントの前にCQRSから
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 6
CQRSとは•Command and Query Responsibility Segregation •コマンド・クエリ責務分離 • 2010年 Greg Young氏が考案したパターン。 •1997年にBertrand Meyer氏が考案したコマンドクエリ分離原則(Command-Query Separation:CQS)をアーキテクチャに適用したものがCQRS。 •「あらゆるメソッドは、アクションを実行するコマンドか、呼び出し元にデータを返すクエリかのいずれかであって、両方を行ってはならない。これは、質問をすることで回答を変化させてはならないということだ。」
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 7
ストレージを分けないCQRS アーキテクチャ• CQSに基づいた最も単純な構成は、ドメイン層をライトとリードの系を分ける。
Client
Write Stack Read Stack
Database
Domain Layer
Application Layer
Infrastructure Layer
Domain Layer
Application Layer
Infrastructure Layer
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 8
ストレージも分けるCQRS アーキテクチャ•ライトとリード系を分析していくと、リード側はクエリ要件に対応するのが目的なのでドメインモデルが不要になる。
Client
Write Stack Read Stack
Database
Domain Layer
Application LayerDAO + DTO
Read Records
Infrastructure Layer
Write Records
ReadModel
形式変換を行う
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 9
そしてドメインイベントへ
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 10
ドメインイベントが主役になるEvent Sourcing• Greg Young氏考案 • Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメインイベントをモデリングの主役とすること。 • ドメインモデルをデータとして格納するのではなく、発生するドメインイベントをすべて永続化する。(基本的に追加しかしない) • ESはCQRSを劇的に改良する(以下 CQRS+ES)。
CartItemAdded { id, cartId, itemId, itemCount }
CartItemCountUpdated { id, cartId, itemId, itemCount }
CartCreated { id, cartId, userId }
CartItemRemoved { id, cartId, itemId }
…
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 11
CQRS+ESアーキテクチャ(1/2)• システムは集約で発生したドメインイベントで駆動しイベントはジャーナルとして永続化される。イベントからのリプレイはSnapshot&Journal。
Client
Write Stack Read Stack
Data Store
DAO + DTO
Read Records
Aggregate
Application Layer
Infrastructure Layer
Event Store
Journals Snapshotsイベントの保存先
CartCreated
CartItemAdded
…
すべてのイベントを永続化
Snapshot+journalsでリプレイ
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 12
CQRS+ESアーキテクチャ(2/2)•コマンドによって生じた集約の状態変化をイベントとして通知する。
Domain Layer
Aggregate
Aggregate Aggregate
Command Command
Event
Command/Event Handler
Event Event
Event
Command
Command/Event HandlerCommand/Event Handler
Event Event
Event
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 13
ドメインイベントとマイクロサービス• BC間の連携にもドメインイベントが利用可能になる。マイクロサービスアーキテクチャと相性がよい。 • ”外部の他の境界づけられたコンテキストには明示的なインターフェイスがあり、そのインターフェイスが他のコンテキストと共有するモデルを決定します。”(マイクロサービスアーキテクチャより) • イベントにはBC内部だけで発生・消費される隠れイベントと外部のBCが関心を持つ共有イベントが存在する。
BC (2)Application
Domain LayerAggregate
BC (1)Application
Domain LayerAggregate
BC (3)Application
Domain LayerAggregate
Event
Event Event
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 14
ここからいきなり戦略の話になります
DDD実践ベストプラクティス
出荷管理チーム
在庫管理チーム
2016/10/24 © ChatWork All rights reserved. 15
マイクロサービスとコンウェイの法則(1/2)• “システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す。” ̶ Melvin Conway(メルヴィン・コンウェイ) • Amazon • 1チームに1サービス • 開発・運用などのライフサイクルの一切の責任を持つ
• 2枚のピザチーム • 2枚のピザで足りないほどのチームは作らない
• Netflixでも最初から小規模なチームで構成し、アーキテクチャのために組織構造を設計した。
在庫管理システム
出荷管理システム
販売管理チーム
販売管理システム
仕入管理チーム
仕入管理システム
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 16
マイクロサービスとコンウェイの法則(2/2)• 単一システム/単一チーム • システム内の閉じた粒度の細かいコミュニケーション特性を持っている。サービス内の変更やリファクタリングは効率的。
• 単一システム/複数チーム • 粒度の細かい閉じたネットワークは局所化される可能性がある(地理的境界がある場合特に)。チーム間を跨がる場合はその特性を欠く場合がある。変更やリファクタリングのコストも相対的に高くなる。大規模システムの保守が難しくなる原因
• 共有サービスに向かう理由 • システムの分割に高いコストを払うケース。 • 複数のサービスに跨がる変更がデリバリーコストをあげてしまうケース。
チームシステム
チーム チーム
システム
ナローバンド
ブロードバンド
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 17
コンウェイの法則とDDDの関係性• マイクロサービスとは、技術ドメインではなく、ビジネスドメインに倣ってモデル化されたサービス。 • モデリング作業に言語能力を活用することの意味 • 図を描くには視覚的・空間的な思考を駆使する。分析する際にコードの感覚を使うのと同様。言語を使うことはそれらと変わらない。 • 役に立つモデルと設計を見つけるにはこの3つすべてが必要になるが言語による実験は見過ごされることが最も多い。
• 境界づけられたコンテキスト=モデルの縄張り • 1つのチームに1つの言語。1つの境界に複数のモデルが存在する場合があるが、別々のモデルが混在するとバグの温床や信頼性の低下や理解しがたくなる。チームのコミュニケーションも混乱を来す。 • モデルが適用される境界を明示的に定義すること。それは、チーム編成、アプリケーション特有の用途、コードベースやスキーマなどの物理的な表現から設定する。その境界内では、モデルを厳密に一貫性のあるものに保つこと。
図
コード 言語
コンテキスト
モデルコンテキスト
モデル
チーム チーム
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 18
まとめ•CQRS •設計がシンプルになる。リード系のユースケースを想定したドメインモデリングから解放される。
•CQRS+ES •CQRSをさらに改良する。ドメインモデルはデータというより出来事=イベントの集合であるという視点が得られる。すべてがイベントで駆動する世界。
•とはいえ、アーキテクチャは組織との関係性を無視できない •アーキテクチャの分離・統合戦略は、組織やコミュニケーションに影響を相互に与え合う。
DDD実践ベストプラクティス
2016/10/24 © ChatWork All rights reserved. 19
おしまい