まえがき

自社開発のWebアプリケーションと、社内だけで運用している業務システムを連携する機能を設計・開発する機会がありました。

今回の要件は、Webアプリケーション上で請求書や見積書のステータスが変更されたときに、その情報を社内運用システムへ連携するというものです。

最初に設計したときは、かなり具体的な業務要件に寄せて考えていました。

たとえば、請求書や見積書のステータスが変更されたタイミングで、そのまま社内運用システムに必要なデータを送信する、という設計です。

この設計でも、現在の要件だけを見ると問題なく動きます。
実装範囲も分かりやすく、処理の流れもシンプルです。

しかし、設計レビューを受けた際に、

特定の用途だけに閉じた機能ではなく、もう少し汎用的な仕組みとして考えたほうがよい

という指摘を受けました。

この指摘を受けて、単に「請求書・見積書のステータス変更時にデータを送る処理」を作るのではなく、「特定のイベントが発生したときに、必要なデータを連携できる仕組み」として設計することが重要だと感じました。

この記事では、そのときの実例をもとに、特定用途に寄せた連携処理と、イベントを意識した連携設計について整理します。

実例

今回の要件では、自社Webアプリケーション上で請求書や見積書のステータスが変更された際に、社内運用システムへデータを送る必要がありました。

当初は、以下のような流れを想定していました。

この設計は、対象業務だけを見ると分かりやすいです。

「請求書・見積書のステータス変更をトリガーに、社内運用システムへデータを送る」という要件に対して、直接的に対応できます。

ただし、この設計には注意点もあります。

業務処理の中に、社内運用システムへの連携処理を直接書いてしまうと、後から送信条件や送信内容を変更したい場合に、業務処理側のコードにも影響が出やすくなります。

たとえば、ステータス変更の処理とデータ送信の処理が密結合になっていると、以下のような状態になりやすいです。

レビューで指摘されたのは、この部分でした。

今回必要だったのは、「請求書・見積書専用の送信処理」を個別に作ることではなく、「ステータス変更というイベントが発生したときに、必要な連携処理を実行する仕組み」として考えることでした。

たとえば、請求書のステータスが変更された場合、業務処理側では「ステータスが変更された」という事実を扱います。

その後、連携処理側で「このステータス変更が発生した場合は、社内運用システムにデータを送る」と判断します。

つまり、以下のように責務を分けるイメージです。

業務処理
  - 請求書のステータスを変更する
  - 見積書のステータスを変更する

イベント発火
  - ステータスが変更されたことを通知する

連携処理
  - 通知された内容をもとに、社内運用システムへデータを送信する

このように分けておくことで、業務処理と連携処理の責務を分離できます。

業務処理側は、ステータス変更という本来の責務に集中できます。
一方で、社内運用システムへ何を送るか、どの条件で送るかは、連携処理側で管理できます。

ただ、設計の考え方として、特定の処理の中に連携処理を直接埋め込むのではなく、「何かが起きたこと」をきっかけに別の処理を動かす形にしておくと、後から変更しやすくなります。

この分離ができていないと、ステータス変更のたびに連携処理が直接実行される形になり、業務ロジックと連携ロジックの境界が曖昧なると感じました。

一方で、イベントを意識して設計しておくと、ステータス変更処理そのものはシンプルに保ちつつ、連携処理の追加や変更にも対応しやすくなります。

今回の設計を通じて、単に要件を満たす実装と、今後の変更を見据えた設計には違いがあると感じました。

請求書・見積書のステータス変更時に社内運用システムへデータを送るだけであれば、個別の送信処理でも実現できます。
しかし、ステータス変更の処理の中に送信処理まで直接書いてしまうと、後から送信条件や送信内容を変えたいときに、ステータス変更処理そのものにも手を入れる必要があります。

そのため、ステータス変更の処理と、社内運用システムへデータを送る処理は分けて考える必要があると感じました。

処理を分けておくことで、後から送信条件や送信内容が変わった場合でも、連携部分だけを修正しやすくなります。