ビジネスルール・エンジンの賢い選択
ローコード・プラットフォームを選択する際に、ビジネスルール・エンジンの検討が非常に重要となります。
ビジネスルール・エンジン
テーブル定義、接続、ビジネスルールの保守管理は、常に怠ることができない課題です。これらをすべてのプログラムにハードコーディングした場合、メンテナンスの負担が増えると同時に、複数箇所に存在する可能性があるため、不整合が発生する恐れもあります。すべての定義、接続、ルールをアプリケーション内ではなく、集中管理されたビジネスルール・エンジンに保管することには、アーキテクチャ上の大きな利点があります。
その利点とは何でしょう?フロントエンドとバックエンドで別々の開発者チームが担当するのではなく、ビジネスルール・エンジンというエンティティ単体のみで、ビジネスルールの定義と実施を行うことで、このルールを徹底することができます。さらに、一旦このルールを定義すれば、どこからでも利用することが可能となります。
ハイエンドのローコード・プラットフォームには、ビジネスルール・エンジンがソリューションの一部として含まれています。現在評価中のローコード・プラットフォームにビジネスルール・エンジンが搭載されている場合、以下を確認してください。
定義の作成・保存・管理を 1 つのリポジトリ内で行えるか？
ビジネスルール・エンジンの基本的な考え方は、データ定義と、そのデータを利用するアプリケーションやデータベースとを分離するということです。また、このリポジトリは、すべての開発者が、簡単に確認でき、アクセスできるものでなければなりません。
定義の保存はデータベース・レベルか、それともアプリケーションレベルか？
定義をデータベース・レベルに保存するモデルは理想的とは言えません。ルールをデータベース・レベルに配置する場合の欠点としては、トリガーやストアド・プロシージャの実装方法が各データベース・ベンダーから独自に提供されるため、結局その特定データベースに固定されてしまうということです。ビジネスルール・エンジンの中には、アプリケーション層にルールを導入することで、このデータベースの囲い込みを回避しようとするものもあります。ただし、そうなると、すべてのプログラムでソースコードが重複し、コードの不整合につながる可能性もあり、管理も困難です。
理想的な配置モデルは、独立したデータ・サービス層を経由するスタイルで、この独立層のビジネスルール・エンジンでは、データベース層とアプリケーション層がゆるく結合されています。このアーキテクチャの利点は、ビジネスルール・エンジン内に加えた変更が、修正や再コンパイルなしに自動的に適用されることです。
例えば、顧客テーブルの郵便番号の検証ルールを更新し、テーブル検索を実行する代わりに RESTful サービスを呼び出す必要があるとします。ビジネスルール・エンジンに変更を加えた後、このデータ・サービス層を利用すると、顧客ファイルにデータを挿入または更新するすべてのプログラムが、顧客テーブルの処理を行うプログラムを再コンパイルする必要なく、直ちに新しい郵便番号ルールを使用できるようになります。
既存データスキーマのインポートは可能か？
どんなプロジェクトであっても、既存のアプリケーションや既存のデータベースを拡張する必要性は出てきます。ローコード・プラットフォーム以外のソースから既存のデータ、スキーマ、ストアド・プロシージャの定義がインポートでき、開発者がビジネスルール・エンジン内で使用できることを確認してください。
ローコード・プラットフォーム以外のプログラムからビジネスルールへのアクセスが可能か？
ローコード、Java、C#、PHP、VB、JavaScript などの開発環境に関係なく、どのアプリケーションからでもビジネスルール・エンジンが利用できるようにしてください。こうすることで、すべてのアプリケーションが、その使用年数やテクノロジーに関係なく、すべてのデータベースI/Oを共通のビジネスルールを使って管理でき、データの精度も大幅に向上します。
ローコード・プラットフォーム以外で使用できないようであれば、再び重複の問題が発生します。重複したルールは、メンテナンスの重複につながります。さらに、重複したメンテナンスは、ビジネスルールの不整合という潜在的な問題を抱えることになるのです。
ビジネスルール・エンジンは、ビジネスルールや検証ロジック以外も保存できるか？
ビジネスルール・エンジンによっては、データベース定義、接続、検証ルール以外も保存できる場合があります。
ローコード・プラットフォーム選択時のキーポイントに関する投稿は次が最後となりますが、次回は、クロス・プラットフォーム・サポートの意味、そしてなぜこれがエンドユーザーに大きな影響を及ぼすのかについて説明します。