Java ロジックエンジンの構想

何年も仕事をしてきて、デザインパターンの重要性を痛感しています。デザインパターンを適切に使えば、複雑なビジネスロジックをより柔軟に実装でき、ポリモーフィズム、拡張性、保守性をより良くサポートできます。ならば一歩進んで——デザインパターンをはじめから内蔵したロジックエンジンを作れないだろうか？このノートでは、その構想を記録しておきます。

解決したい問題

バックエンドのビジネス開発には気まずい現実があります。大量のコードは実のところ同じ骨組みの繰り返しなのです——パラメータを受け取り、データを検索し、条件によって分岐し、結果を組み立て、永続化する。毎回この流れを手書きしなければならず、デザインパターンをうまく使える人はそれをきれいに抽象化しますが、そうでない人は巨大な if-else の塊を書いてしまいます。

問題は開発者がデザインパターンを理解していないことではなく、プロジェクトごとにファクトリやストラテジーといったパターンを改めて実装し直さなければならず、その実装品質もまちまちだという点にあります。もしこの抽象化の層をエンジンに沈殿させることができれば、ビジネス開発は本当のビジネスロジックそのものにだけ集中すればよくなります。

コアとなる構想

私の構想はこうです。バックエンドの Java 開発者のためにあつらえた、デザインパターンをはじめから備えた UI ロジックエンジンを設計する。開発者はロジックコンポーネントを組み合わせ、コンポーネントをダブルクリックして SQL や Java コードを書き、コンポーネントのメンバー変数をコンポーネント間で受け渡し、最終的に永続化するだけです。

原理は現在の Kettle ツールに似ています——Kettle がやっているのはデータ抽出・変換のビジュアルな編成ですが、このエンジンがやるのはビジネスロジックのビジュアルな編成です。

コンポーネントは最小のロジック単位で、各コンポーネントは 1 つのことだけを行います。1 回のクエリ、1 回のバリデーション、1 回の計算、あるいは 1 回の書き込みです。複雑なビジネスとは、これらの単位を順序や条件に従って組み合わせた 1 枚のフローチャートにほかなりません。こうしたロジックエンジンがあれば、Java 開発は間違いなく重複作業を大幅に減らせるはずです。

デザインパターンがどう支えるか

この構想のインスピレーションは、私が仕事で実際に使っているいくつかのパターンの組み合わせから来ています。ファクトリパターン、プロキシパターン、ストラテジーパターン、デコレーターパターン、そして SPI の考え方です。エンジンの中でそれぞれに役割分担があります。

1. ファクトリパターン: 設定に基づいて具体的なロジックコンポーネントのインスタンスを生成する役割を担います。UI 上でドラッグして配置した各ノードは、実行時にファクトリが対応するオブジェクトを産出します。

2. ストラテジーパターン: 各ロジックコンポーネントは 1 つのストラテジー実装であり、同じフローノードは全体の編成に影響を与えることなく別の実装に差し替えられます。

3. プロキシパターン: 実行の入口をプロキシストラテジークラスに集約し、パラメータの受け渡しや例外処理といった横断的なロジックを一手に引き受けてから、本当のコンポーネントへ転送します。

4. デコレーターパターン: コンポーネント自体に手を加えることなく能力を積み重ねます。たとえばあるコンポーネントにログやキャッシュの外殻を被せる、といった具合です。

5. SPI の考え方: コンポーネントは取り決められたインターフェースで外部に公開され、新しいコンポーネントはインターフェースに従って実装・登録するだけでエンジンに発見されます。エンジン自体のコードを変更する必要はありません。

実行の仕組み

全体の流れは設定駆動です。UI コンポーネントから設定ファイルを生成し、設定ファイルがプロキシストラテジークラスに、その中の対応するコンポーネントロジック単位の .class ファイルを呼び出すよう指示します。システム起動時にすべてのロジックストラテジーをロードし、これらの Spring Bean が正常にメモリへロードされることを保証します——クラスロードと Bean 初期化のコストを起動時に済ませておき、実行時にはテーブル参照と転送だけを行うのです。

以降の実行はすべてプロキシストラテジークラスを通じてロジック処理を行い、個々の Bean を組み立てることで、1 つの複雑なビジネスロジックを完成させます。

このような実装は単一責任の原則とオープン・クローズドの原則にも適っています。各コンポーネントは責務が単一で、ビジネスの追加はコンポーネントの追加と設定の変更によって行われ、既存コードの修正によっては行われません。

ローコードプラットフォームとの関係

現在の市場でこの構想に対応するプロダクトといえば、ローコードプラットフォームやノーコードプラットフォームになるのでしょう。ただし位置づけには違いがあります。ローコードプラットフォームの多くはビジネス担当者やフルスタックのシーンに向いていて、ページまで含めて生成しようとします。一方この構想はバックエンドの Java 開発者だけに向いており、SQL や Java コードを書くことを避けず、編成とデザインパターンという骨組みの層だけをエンジンに委ねます。

これこそが、私がこの構想は実現可能だと考える理由です——「コードを書かない」ことを追求するのではなく、「重複する構造コードを書かない」ことだけを追求するのです。

まとめ

このノートは本質的に、あるアイデアのアーカイブです。ファクトリ、プロキシ、ストラテジー、デコレーターと SPI を組み合わせて設定駆動のロジックエンジンを作り、手書きのフローの骨組みをビジュアルな編成で置き換える。必ずしも大きくて何でも揃ったプラットフォームに仕立てる必要はありません。まずは 1 つのプロジェクトで「コンポーネント + 設定 + プロキシストラテジー」というこの仕組みを通しで動かすだけでも、この方向性の価値を検証することができるでしょう。