ドメインイベントを設計する / Modeling the Domain Event

65cc101435ac36057f2a2c80244c4c6e?s=47 Yoshitaka Okuda
September 29, 2016

ドメインイベントを設計する / Modeling the Domain Event

第3回Reactive System Meetup in 西新宿 でのLT発表資料です。
http://reactive-shinjuku.connpass.com/event/38411/

なお、10分にはおさまらなかった模様...
補足記事:http://yoskhdia.hatenablog.com/entry/2016/09/29/214318

65cc101435ac36057f2a2c80244c4c6e?s=128

Yoshitaka Okuda

September 29, 2016
Tweet

Transcript

  1. υϝΠϯΠϕϯτΛઃܭ͢Δ Reactive Messaging Patterns͓Αͼ Implementing Domain−Driven DesignΑΓ 2016/09/29 @yoskhdia ୈ3ճReactive

    System Meetup in ੢৽॓ ϋογϡλάɿ#reactive_shinjuku NJO
  2. About me • ԞాՂڗʢYoshitaka Okudaʣ • גࣜձࣾSocketʢKDDI Syn.ϗʔϧσΟϯάεάϧʔϓʣ
 ΞʔΩςΫτ •

    Twitterɹɹ @yoskhdia • interested in DDD & Reactive System & Team Building & more !
  3. Agenda • メッセージの種類 • ドメインイベントの設計 ※メッセージ駆動の手段は色々あると思いますが、
 書籍「Reactive Messaging Patterns with

    the Actor Model」
 をベースに進めます。 ※DDD(Domain-Driven Design)成分強めです。
  4. ϝοηʔδͷछྨʢେ·͔ʣ • Command Message • Point-to-Pointで送るのが基本。Commandはそれ自体がActor の振る舞いを表現する。Receiverが正しく振る舞えるように データなどを内包する。(結果を返して欲しい場合Query) • Document

    Message • 情報を伝達するために使う。ただし、そのデータをどう使う かは指し示さない。Commandを送ってきたSenderへの返答とし て使用される。(Request-Reply) • Event Message • Pub/Subを使うなど、不特定多数にブロードキャストする。 (Commandによって)起きた出来事として使用される。
  5. DocumentͱEventͷҧ͍ 4FOEFS 3FDFJWFS 4FOEFS 3FDFJWFS தܧ໾ Document Message Event Message

    違いは内容とタイミングの重視具合。 Documentは内容が重要で多少遅れても 確実に届けたいもの。 (Guaranteed Deliveryなど) Eventはタイミングが重要で発生したら すぐに発行するもの。
  6. υϝΠϯΠϕϯτͷઃܭ

  7. υϝΠϯΠϕϯτͱ͸ • ドメインエキスパートが気にかける、何かの 出来事(IDDD p.274) • DDD本執筆時はドラフトだったため未収録 • DDD Referenceでは収録されている

    • 実装する手段としてEvent Message • 逆に言えばドメインイベントを学ぶと良い Event Message設計のヒントになる
  8. υϝΠϯΠϕϯτͷݟ͚ͭํ • 別の集約の状態に依存している集約を見つけるのが簡単 • 「〜するときに、」 • 「もしそうなったら、〜」 • 「〜の場合は、私に知らせて欲しい」「〜の場合は、 通知して欲しい」

    • 「〜が発生したときに、」 • すべてがドメインイベントになるわけではないけれど、 これらのフレーズには注意を向ける必要がある。
  9. υϝΠϯΠϕϯτͷઃܭ • 名前やプロパティは、イベント発生元の境界づ けられたコンテキストのユビキタス言語に沿っ たものにする。 • その出来事が過去に発生したことがわかるよう な名前にする(発生した事実を名前に!) • 集約上で何らかのコマンドを実行した結果とし

    て発生するイベントの場合は、実行したコマン ドにもとづくイベント名を使うことが多い。 • ヒント:イミュータブルデータモデル(入門編)
  10. ઃܭͷ஫ҙ఺ • イベントはイミュータブルにする • 何が発生したのかをきちんと表すようにプロパティを持たせる • 通常は、発生要因の情報(集約の識別子など)を持たせる。 • Receiverがイベントの発行元の集約に追加の問い合わせをする ことは避けるべき。複雑化を招き、処理コストも増大して、

    メッセージである必要性が薄れる。Receiverが発生要因以外に も情報を必要とするなら、イベントに新たな情報と振る舞いを 追加することはある。 • 他方のアプリケーションが、オブジェクト全体のコピーを持つ ことはまずない。そのため、購読側がそのイベントに対応でき る必要最小限の情報だけを含めるようにする。(それがどうし てもできないときは、RPCを使わざるを得なくなることもある。)
  11. ΠϕϯτΛू໿ͱͯ͠ѻ͏ • 集約から発行される以外にも、ユーザのアクションによって、 クライントから直接イベントが作られる設計をすることもあ る。 • この場合、イベントを集約としてモデリングし、リポジトリに 保持させることができる。イベントは過去の出来事を表すもの なので、リポジトリは集約の変更・削除を許可しない。 •

    イベントをこの方式でモデリングする場合は、集約と同様、イ ベントもモデルの構造の一部となる。したがって、このイベン トは単なる過去の出来事の記録ではなくなる。(IDDD p.282) • エンティティと同様に一意な識別子を割り当てても良い。 (様々な変更が加わってもイベントの一意性が守られるので好 ましい。特に外部へ送信するような場合。)
  12. υϝΠϯΠϕϯτ͸࿬໾Ͱ͸ͳ͘ ୈҰڃͷυϝΠϯΦϒδΣΫτ ʹͳΓಘΔ

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

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

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

  16. ӬଓԽͷ஫ҙ఺ • リポジトリに格納すると同時に、メッセージング基盤を使っ て発行することができる。クライアント→ドメインサービス →イベント作成→リポジトリへ追加→メッセージング基盤 • メッセージングを利用する場合、ドメインモデルが利用する 永続化ストアと、メッセージング基盤が使う永続化ストアの 整合性は保たなければならない。例えば以下の選択肢。 •

    同一のローカルトランザクションを利用する。 • グローバルなXAトランザクション(二相コミット)で制御 する。 • イベント用の特別なストレージをドメインモデルが使って いるのと同じデータストア内に用意する。
  17. খʁ·ͱΊ • MessagingのひとつにEvent Messageがある • 良いEvent Message設計のヒントにDDDのドメ インイベントが使える • ミュータブルな領域を狭め、イミュータブル

    な領域と住み分けることで、複雑性が低減し 変化に適応しやすくなる • EventSourcing程いかなくても、ドメインイベ ントをモデリングすることは非常に有用
  18. ͱ͸͍͑ɺ࣮૷໘Ͱ͸ ୔ࢁͷߟྀࣄ߲͕͋Δ

  19. Reactive Messaging Patterns with the Actor Model ʴ

  20. ୔ࢁͷ༗༻ͳύλʔϯ͕ʂ • Correlation Identifier • Message Sequence • Message Expiration

    • Format Indicator • Canonical Data Model • etc etc etc...
  21. ワシのパターンは百八式まであるぞ・・・ ※そんなにはありません

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

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

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

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

  26. ·ͱΊ • 書籍「Enterprise Integration Patterns」に はエンタープライズ領域でのシステム構築で使 えるヒントがいっぱい。 • 書籍「Reactive Messaging

    Patterns」はEIPを ベースにして、Actor Modelへの適応を考察し ている。 • Akkaの登場によってEIPの実践が(より)現実 のものになった。 • Messagingはモデリングにも有用
  27. ࢀߟ • 書籍「実践ドメイン駆動設計」 • 書籍「Reactive Messaging Patterns with the Actor

    Model」 • EIP - Java EE勉強会 • イミュータブルデータモデル(入門編)