本記事について

以下の記事にて、バッチ処理の設計に関する新たなアプローチを提案しました。

この記事では、前回の設計がもたらす、当初は予測していなかった応用例について掘り下げていきます。

DDDの原則

ドメイン駆動設計（DDD）の原則に則り、計算ロジックを永続化から独立したドメインモデルとして切り出したことで、それをデータベースに保存するだけでなく、メモリ上のオブジェクトといった一時的なデータに対しても適用することが可能になりました。

バッチ処理については「もしこの条件だったら、結果はどうなるか」という試算（シミュレーション）が必要になる場面があります。（料金改定などを想定）

従来、この試算は困難な作業でした。

なぜなら、システムの計算ロジックがデータベースへの永続化と密結合していたため、本番データに影響を与えずにロジックだけを安全に実行するのは手間がかかりました。

結果として、担当者がソースコードを読み解き、手作業でバッチ処理のロジックを再現するという、時間と手間のかかるプロセスに頼っていました。

しかし、ドメインモデルが永続化から分離されたことで変わりました。

本番のデータベースではなく、メモリ上の一時的なデータに対して、本番と全く同じドメインモデルを適用できます。

これにより、これまで手作業で行っていた複雑な試算業務を、システム化できました。

もう一つの価値は、データ分析の領域で生まれます。

従来のバッチ処理が永続化してきたのは、多くの場合、「最終的な請求額」や「集計後のKPI」といった、あらかじめ定義された指標のみでした。

これは都度の要件に応じた個別対応の積み重ねであり、その内訳となる計算プロセスは失われていました。

前回の記事で提案した設計は、この制約を取り払いました。

「ゴールド会員割引」や「送料無料ルール」といった、計算プロセスを構成するすべてのルール適用が「事実」として記録されます。

これにより、これまで不可能だったルール別の詳細な集計や分析が可能になります。

IT部門にデータ抽出を依頼せずとも、業務担当者やデータアナリストが自らの手で、「特定の割引が収益に与える影響は？」「どのオプションの利益率が高いのか？」といった、より深いビジネス上の問いにデータで答えを出すことができるようになります。

システムの記録するデータが、ビジネスを分析するための基盤になります。

ビジネスの本質を捉えたドメインモデルの分離は、当初の目的であった保守性の向上に留まらず、シミュレーションやデータ分析といった、私が当初、予測していなかった新たな価値を生み出す土壌となりました。