イベント設計のシンプルなヒューリスティック「誰が誰を呼ぶべきか？」（翻訳）
2つのコンポーネントを統合するとき、両者間の通信に使いたいコマンドやイベントをどちらのコンポーネントが所有すべきかで悩んだことはありませんか？今回は、そうした決定を下すときに役立つ手軽なヒューリスティック（発見的方法）を紹介します。
このヒューリスティックは、コンポーネント内でどの程度頻繁に変更が発生するかに依存します。実践する前に、これらのコンポーネント同士の関係を視覚化する必要があります。
コンテキストマッピング（Context Mapping）は、1個の境界付きコンテキスト（Bounded Context）を変更したときに他の境界付きコンテキストにどんな影響を与えるかを図示できるので、そういう場合に最適なツールです（コンテキストマッピングの概念については以下に優れたリソースがあります）。
それでは早速例を見ていくことにしましょう。
「Registration（登録）」と「Payment（支払い）」という2つのコンポーネントがあるとします。Registrationコンポーネントには、変更される可能性のあるルール（緑の点は1個の変更を表します）がいくつか含まれているため、Registrationコンポーネントは頻繁に変更されます。一方、Paymentコンポーネントはめったに変更されません。
ここで、2つのコンポーネント間の通信をRegistration側のコマンド/イベント（インターフェイス）で行うという決定が下されたとします。
このとき、2つのコンポーネント間の上流（upstream）/下流（downstream）関係も同時に定義されることになります。Registrationは上流側になります。
これは、Registrationで変更が発生するとPaymentでも何らかの変更が発生する可能性が高くなることも意味するので、2つのコンポーネント間の癒着が強まります。
この癒着を弱めるには、上流/下流関係の向きを変える必要があります。これは、コマンド/イベントをPayment側で使うようにすることで実現できます。
ここで注目していただきたいのは、どちらのコンポーネントを上流とするかによってインターフェイスの命名も変わってくることです。こういう実験を行ってみることで、設計上の視点が変わってくることもあるのです。
ここで説明したヒューリスティックを用いることで、コンポーネント間の関係を修正したり、新たな境界付きコンテキストを上手に作成できるようになるでしょう。もちろん、モデルの変更と契約（contract）の変更のどちらを重んじるかといった設計上の微妙な点は常にありますが、それについては別のトピックになりそうです😉
概要
元サイトの許諾を得て翻訳・公開いたします。
日本語タイトルは内容に即したものにしました。