DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event...

19
DDD実践(ベスト)プラクティス {ドメインイベントと マイクロサービスと 組織の関係} 加藤潤一(かとじゅん) ChatWork 2016/10/24

Transcript of DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event...

Page 1: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践(ベスト)プラクティス{ドメインイベントとマイクロサービスと組織の関係}

加藤潤一(かとじゅん) ChatWork 2016/10/24

Page 2: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/3/26 © ChatWork All rights reserved.

自己紹介

•@j5ik2o •ChatWorkでテックリードをやっています。 •過去はSeasar2/Java、今はScala/Akkaが主戦場。 •最近は CQRS+ES, Akkaなどを使って仕事をしています。 •DDDで迷子になってたら声かけてください。アドバイスします。

Page 3: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved.

アジェンダ•タイトル先行で考えた→書いているうちにベストなプラクティスじゃなくてもいいとなったので、ベストかどうかはさておきという前提で…。 • CQRSとは • CQRS + Event Sourcingとは • ドメインイベントとマイクロサービス • マイクロサービスとコンウェイの法則 • コンウェイの法則とDDDの関係性

Page 4: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 4

開発者の方が多いと思うので 戦術の話から

Page 5: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 5

ドメインイベントの前にCQRSから

Page 6: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

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。 •「あらゆるメソッドは、アクションを実行するコマンドか、呼び出し元にデータを返すクエリかのいずれかであって、両方を行ってはならない。これは、質問をすることで回答を変化させてはならないということだ。」

Page 7: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

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

Page 8: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

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

形式変換を行う

Page 9: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 9

そしてドメインイベントへ

Page 10: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

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 }

Page 11: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

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でリプレイ

Page 12: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

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

Page 13: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

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

Page 14: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 14

ここからいきなり戦略の話になります

Page 15: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

出荷管理チーム

在庫管理チーム

2016/10/24 © ChatWork All rights reserved. 15

マイクロサービスとコンウェイの法則(1/2)• “システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す。” ̶ Melvin Conway(メルヴィン・コンウェイ) • Amazon • 1チームに1サービス • 開発・運用などのライフサイクルの一切の責任を持つ

• 2枚のピザチーム • 2枚のピザで足りないほどのチームは作らない

• Netflixでも最初から小規模なチームで構成し、アーキテクチャのために組織構造を設計した。

在庫管理システム

出荷管理システム

販売管理チーム

販売管理システム

仕入管理チーム

仕入管理システム

Page 16: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 16

マイクロサービスとコンウェイの法則(2/2)• 単一システム/単一チーム • システム内の閉じた粒度の細かいコミュニケーション特性を持っている。サービス内の変更やリファクタリングは効率的。

• 単一システム/複数チーム • 粒度の細かい閉じたネットワークは局所化される可能性がある(地理的境界がある場合特に)。チーム間を跨がる場合はその特性を欠く場合がある。変更やリファクタリングのコストも相対的に高くなる。大規模システムの保守が難しくなる原因

• 共有サービスに向かう理由 • システムの分割に高いコストを払うケース。 • 複数のサービスに跨がる変更がデリバリーコストをあげてしまうケース。

チームシステム

チーム チーム

システム

ナローバンド

ブロードバンド

Page 17: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 17

コンウェイの法則とDDDの関係性• マイクロサービスとは、技術ドメインではなく、ビジネスドメインに倣ってモデル化されたサービス。 • モデリング作業に言語能力を活用することの意味 • 図を描くには視覚的・空間的な思考を駆使する。分析する際にコードの感覚を使うのと同様。言語を使うことはそれらと変わらない。 • 役に立つモデルと設計を見つけるにはこの3つすべてが必要になるが言語による実験は見過ごされることが最も多い。

• 境界づけられたコンテキスト=モデルの縄張り • 1つのチームに1つの言語。1つの境界に複数のモデルが存在する場合があるが、別々のモデルが混在するとバグの温床や信頼性の低下や理解しがたくなる。チームのコミュニケーションも混乱を来す。 • モデルが適用される境界を明示的に定義すること。それは、チーム編成、アプリケーション特有の用途、コードベースやスキーマなどの物理的な表現から設定する。その境界内では、モデルを厳密に一貫性のあるものに保つこと。

コード 言語

コンテキスト

モデルコンテキスト

モデル

チーム チーム

Page 18: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 18

まとめ•CQRS •設計がシンプルになる。リード系のユースケースを想定したドメインモデリングから解放される。

•CQRS+ES •CQRSをさらに改良する。ドメインモデルはデータというより出来事=イベントの集合であるという視点が得られる。すべてがイベントで駆動する世界。

•とはいえ、アーキテクチャは組織との関係性を無視できない •アーキテクチャの分離・統合戦略は、組織やコミュニケーションに影響を相互に与え合う。

Page 19: DDD実践 ベスト プラクティス {ドメインイベントと マイクロ … · •Event Sourcing(以下 ES)とは、データではなく何かしらの出来事=ドメ

DDD実践ベストプラクティス

2016/10/24 © ChatWork All rights reserved. 19

おしまい