ドメインイベントを設計する / 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. 2.

    About me • ԞాՂڗʢYoshitaka Okudaʣ • גࣜձࣾSocketʢKDDI Syn.ϗʔϧσΟϯάεάϧʔϓʣ
 ΞʔΩςΫτ •

    Twitterɹɹ @yoskhdia • interested in DDD & Reactive System & Team Building & more !
  2. 4.

    ϝοηʔδͷछྨʢେ·͔ʣ • Command Message • Point-to-Pointで送るのが基本。Commandはそれ自体がActor の振る舞いを表現する。Receiverが正しく振る舞えるように データなどを内包する。(結果を返して欲しい場合Query) • Document

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

    DocumentͱEventͷҧ͍ 4FOEFS 3FDFJWFS 4FOEFS 3FDFJWFS தܧ໾ Document Message Event Message

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

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

    • 実装する手段としてEvent Message • 逆に言えばドメインイベントを学ぶと良い Event Message設計のヒントになる
  5. 8.

    υϝΠϯΠϕϯτͷݟ͚ͭํ • 別の集約の状態に依存している集約を見つけるのが簡単 • 「〜するときに、」 • 「もしそうなったら、〜」 • 「〜の場合は、私に知らせて欲しい」「〜の場合は、 通知して欲しい」

    • 「〜が発生したときに、」 • すべてがドメインイベントになるわけではないけれど、 これらのフレーズには注意を向ける必要がある。
  6. 10.

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

    メッセージである必要性が薄れる。Receiverが発生要因以外に も情報を必要とするなら、イベントに新たな情報と振る舞いを 追加することはある。 • 他方のアプリケーションが、オブジェクト全体のコピーを持つ ことはまずない。そのため、購読側がそのイベントに対応でき る必要最小限の情報だけを含めるようにする。(それがどうし てもできないときは、RPCを使わざるを得なくなることもある。)
  7. 11.

    ΠϕϯτΛू໿ͱͯ͠ѻ͏ • 集約から発行される以外にも、ユーザのアクションによって、 クライントから直接イベントが作られる設計をすることもあ る。 • この場合、イベントを集約としてモデリングし、リポジトリに 保持させることができる。イベントは過去の出来事を表すもの なので、リポジトリは集約の変更・削除を許可しない。 •

    イベントをこの方式でモデリングする場合は、集約と同様、イ ベントもモデルの構造の一部となる。したがって、このイベン トは単なる過去の出来事の記録ではなくなる。(IDDD p.282) • エンティティと同様に一意な識別子を割り当てても良い。 (様々な変更が加わってもイベントの一意性が守られるので好 ましい。特に外部へ送信するような場合。)
  8. 17.

    খʁ·ͱΊ • MessagingのひとつにEvent Messageがある • 良いEvent Message設計のヒントにDDDのドメ インイベントが使える • ミュータブルな領域を狭め、イミュータブル

    な領域と住み分けることで、複雑性が低減し 変化に適応しやすくなる • EventSourcing程いかなくても、ドメインイベ ントをモデリングすることは非常に有用
  9. 20.

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

    • Format Indicator • Canonical Data Model • etc etc etc...
  10. 26.

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

    Patterns」はEIPを ベースにして、Actor Modelへの適応を考察し ている。 • Akkaの登場によってEIPの実践が(より)現実 のものになった。 • Messagingはモデリングにも有用
  11. 27.

    ࢀߟ • 書籍「実践ドメイン駆動設計」 • 書籍「Reactive Messaging Patterns with the Actor

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