iwashi / Yoshimasa Iwase(@iwashi86):ビジネスロジックにおける事実と、その結果をドメインイベントで分離しよう、という設計話。・ビジネスロジックは「何かが起きたら、別の何かをする」という形になりがち・これを直接書くと、事実とその結果の処理が密結合してしまう・例えば注文処理のコード内に、メール送信やデータ分析への記録が混ざる・エラー処理が複雑になり、どの事後処理が必須なのかも分かりにくくなる・そこで、システム内で起きた事実をドメインイベントとして記録する・このイベントは、変更不可能な記録として扱う・要求を拒否できるコマンドとは異なり、イベントは既に確定した事実となる・実装としては、集約の中でルールを検証し、状態を変えてからイベントを記録する・その事実に対し、各ハンドラーが独立して事後処理（メール送信など）を実行・これで新しい事後処理を追加しても、元の注文ロジックを修正せずに済む・ただ、すべての状態変更を無闇にイベント化するべきではない・イベントが役立つのは、その変更がドメイン上の意味のある事実を表しており、一つ以上の利用者がそれに反応する必要がある場合元記事はコードもあるので、詳細はそちらに。

iwashi / Yoshimasa Iwase

@iwashi86

NTTドコモビジネスでEM(育休中)。その他に、早稲田大で非常勤講師、#fukabori#.fmの中の人、書籍翻訳者。 AI、マネジメント、Dev、PdM、Agile、HRに関する学びをポストしています。発言は個人の見解であり、所属する組織の公式見解ではありません。 Amazonアソシエイト・プログラム参加者。

参加 May 2009

682 フォロー中 20.1K ファン

iwashi / Yoshimasa Iwase@iwashi86

2026.07.27 07:00

ビジネスロジックにおける事実と、その結果をドメインイベントで分離しよう、という設計話。・ビジネスロジックは「何かが起きたら、別の何かをする」という形になりがち・これを直接書くと、事実とその結果の処理が密結合してしまう・例えば注文処理のコード内に、メール送信やデータ分析への記録が混ざる・エラー処理が複雑になり、どの事後処理が必須なのかも分かりにくくなる・そこで、システム内で起きた事実をドメインイベントとして記録する・このイベントは、変更不可能な記録として扱う・要求を拒否できるコマンドとは異なり、イベントは既に確定した事実となる・実装としては、集約の中でルールを検証し、状態を変えてからイベントを記録する・その事実に対し、各ハンドラーが独立して事後処理（メール送信など）を実行・これで新しい事後処理を追加しても、元の注文ロジックを修正せずに済む・ただ、すべての状態変更を無闇にイベント化するべきではない・イベントが役立つのは、その変更がドメイン上の意味のある事実を表しており、一つ以上の利用者がそれに反応する必要がある場合元記事はコードもあるので、詳細はそちらに。