υϝΠϯΠϕϯτΛઃܭ͢Δ Reactive Messaging Patterns͓Αͼ Implementing Domain−Driven DesignΑΓ 2016/09/29 @yoskhdia ୈ3ճReactive System Meetup in ੢৽॓ ϋογϡλάɿ#reactive_shinjuku NJO

About me • ԞాՂڗʢYoshitaka Okudaʣ • גࣜձࣾSocketʢKDDI Syn.ϗʔϧσΟϯάεάϧʔϓʣ
 ΞʔΩςΫτ • Twitterɹɹ @yoskhdia • interested in DDD & Reactive System & Team Building & more !

Agenda • メッセージの種類 • ドメインイベントの設計 ※メッセージ駆動の手段は色々あると思いますが、
 書籍「Reactive Messaging Patterns with the Actor Model」
 をベースに進めます。 ※DDD（Domain-Driven Design）成分強めです。

ϝοηʔδͷछྨʢେ·͔ʣ • Command Message • Point-to-Pointで送るのが基本。Commandはそれ自体がActor の振る舞いを表現する。Receiverが正しく振る舞えるように データなどを内包する。（結果を返して欲しい場合Query） • Document Message • 情報を伝達するために使う。ただし、そのデータをどう使う かは指し示さない。Commandを送ってきたSenderへの返答とし て使用される。（Request-Reply） • Event Message • Pub/Subを使うなど、不特定多数にブロードキャストする。 （Commandによって）起きた出来事として使用される。

DocumentͱEventͷҧ͍ 4FOEFS 3FDFJWFS 4FOEFS 3FDFJWFS தܧ໾ Document Message Event Message 違いは内容とタイミングの重視具合。 Documentは内容が重要で多少遅れても 確実に届けたいもの。 （Guaranteed Deliveryなど） Eventはタイミングが重要で発生したら すぐに発行するもの。

υϝΠϯΠϕϯτͷઃܭ

υϝΠϯΠϕϯτͱ͸ • ドメインエキスパートが気にかける、何かの 出来事(IDDD p.274) • DDD本執筆時はドラフトだったため未収録 • DDD Referenceでは収録されている • 実装する手段としてEvent Message • 逆に言えばドメインイベントを学ぶと良い Event Message設計のヒントになる

υϝΠϯΠϕϯτͷݟ͚ͭํ • 別の集約の状態に依存している集約を見つけるのが簡単 • 「〜するときに、」 • 「もしそうなったら、〜」 • 「〜の場合は、私に知らせて欲しい」「〜の場合は、 通知して欲しい」 • 「〜が発生したときに、」 • すべてがドメインイベントになるわけではないけれど、 これらのフレーズには注意を向ける必要がある。

υϝΠϯΠϕϯτͷઃܭ • 名前やプロパティは、イベント発生元の境界づ けられたコンテキストのユビキタス言語に沿っ たものにする。 • その出来事が過去に発生したことがわかるよう な名前にする（発生した事実を名前に！） • 集約上で何らかのコマンドを実行した結果とし て発生するイベントの場合は、実行したコマン ドにもとづくイベント名を使うことが多い。 • ヒント：イミュータブルデータモデル(入門編)

ઃܭͷ஫ҙ఺ • イベントはイミュータブルにする • 何が発生したのかをきちんと表すようにプロパティを持たせる • 通常は、発生要因の情報（集約の識別子など）を持たせる。 • Receiverがイベントの発行元の集約に追加の問い合わせをする ことは避けるべき。複雑化を招き、処理コストも増大して、 メッセージである必要性が薄れる。Receiverが発生要因以外に も情報を必要とするなら、イベントに新たな情報と振る舞いを 追加することはある。 • 他方のアプリケーションが、オブジェクト全体のコピーを持つ ことはまずない。そのため、購読側がそのイベントに対応でき る必要最小限の情報だけを含めるようにする。（それがどうし てもできないときは、RPCを使わざるを得なくなることもある。）

ΠϕϯτΛू໿ͱͯ͠ѻ͏ • 集約から発行される以外にも、ユーザのアクションによって、 クライントから直接イベントが作られる設計をすることもあ る。 • この場合、イベントを集約としてモデリングし、リポジトリに 保持させることができる。イベントは過去の出来事を表すもの なので、リポジトリは集約の変更・削除を許可しない。 • イベントをこの方式でモデリングする場合は、集約と同様、イ ベントもモデルの構造の一部となる。したがって、このイベン トは単なる過去の出来事の記録ではなくなる。（IDDD p.282） • エンティティと同様に一意な識別子を割り当てても良い。 （様々な変更が加わってもイベントの一意性が守られるので好 ましい。特に外部へ送信するような場合。）

υϝΠϯΠϕϯτ͸࿬໾Ͱ͸ͳ͘ ୈҰڃͷυϝΠϯΦϒδΣΫτ ʹͳΓಘΔ

ϛϡʔλϒϧͳ΋ͷͱ Πϛϡʔλϒϧͳ΋ͷΛ ෼͚ΒΕΔ

Πϛϡʔλϒϧͳ΋ͷ͸ ߋ৽͕ແ͍ͷͰ ϞσϧͷෳࡶੑΛ௿ݮͤ͞Δ

ϛϡʔλϒϧͳྖҬΛ ڱΊͯ ϞσϧͷෳࡶੑΛ௿ݮͤ͞Δ

ӬଓԽͷ஫ҙ఺ • リポジトリに格納すると同時に、メッセージング基盤を使っ て発行することができる。クライアント→ドメインサービス →イベント作成→リポジトリへ追加→メッセージング基盤 • メッセージングを利用する場合、ドメインモデルが利用する 永続化ストアと、メッセージング基盤が使う永続化ストアの 整合性は保たなければならない。例えば以下の選択肢。 • 同一のローカルトランザクションを利用する。 • グローバルなXAトランザクション（二相コミット）で制御 する。 • イベント用の特別なストレージをドメインモデルが使って いるのと同じデータストア内に用意する。

খʁ·ͱΊ • MessagingのひとつにEvent Messageがある • 良いEvent Message設計のヒントにDDDのドメ インイベントが使える • ミュータブルな領域を狭め、イミュータブル な領域と住み分けることで、複雑性が低減し 変化に適応しやすくなる • EventSourcing程いかなくても、ドメインイベ ントをモデリングすることは非常に有用

ͱ͸͍͑ɺ࣮૷໘Ͱ͸ ୔ࢁͷߟྀࣄ߲͕͋Δ

Reactive Messaging Patterns with the Actor Model ʴ

୔ࢁͷ༗༻ͳύλʔϯ͕ʂ • Correlation Identifier • Message Sequence • Message Expiration • Format Indicator • Canonical Data Model • etc etc etc...

ワシのパターンは百八式まであるぞ・・・ ※そんなにはありません

ͻͱΓͰಡΊΔ͔ͳɾɾɾ

こんなところに読書会が！奇遇ですね！ ※宣伝です

࣮ફ͢Δͷ͸ෆ͕҆Ұഋɾɾɾ

こんなところにコンサルティングサービスが！奇遇ですね！ ※オチにしてごめんなさい

·ͱΊ • 書籍「Enterprise Integration Patterns」に はエンタープライズ領域でのシステム構築で使 えるヒントがいっぱい。 • 書籍「Reactive Messaging Patterns」はEIPを ベースにして、Actor Modelへの適応を考察し ている。 • Akkaの登場によってEIPの実践が（より）現実 のものになった。 • Messagingはモデリングにも有用

ࢀߟ • 書籍「実践ドメイン駆動設計」 • 書籍「Reactive Messaging Patterns with the Actor Model」 • EIP - Java EE勉強会 • イミュータブルデータモデル(入門編)