マルチテナントシステムの拡張性をどのように管理しますか？

現在、いくつかの大きなWebベースのマルチテナント製品がありますが、すぐにテナント固有のカスタマイズが多数行われることがわかります。

あちこちの余分なフィールド、おそらく余分なページ、またはワークフローの途中の追加のロジック-そのようなこと。

これらのカスタマイズの一部は、コア製品に組み込むことができ、それは素晴らしいことです。それらのいくつかは非常に具体的であり、他の人の邪魔になります。

これを管理するためのいくつかのアイデアを念頭に置いていますが、どれもうまく拡張できないようです。明らかな解決策は、クライアントレベルの設定を多数導入し、クライアントごとにさまざまな「機能」を有効にすることです。それの欠点は、もちろん、非常に複雑で混乱していることです。本当に膨大な数の設定を導入でき、時間の経過とともにさまざまなタイプのロジック（プレゼンテーション、ビジネス）が手に負えなくなる可能性があります。次に、クライアント固有のフィールドの問題があります。これは、既存のテーブルに多数のNULL可能フィールドを追加するだけでなく、よりクリーンなものを要求します。

では、これを管理するために人々は何をしているのでしょうか？Force.comは拡張性のマスターのようです。明らかに、彼らは一からプラットフォームを作成し、それは超拡張可能です。WebベースのUIを使用して、ほぼすべてに追加できます。FogBugzは、実際にForceに触発された可能性のある堅牢なプラグインモデルを作成するのと似たようなことをしました。私は彼らがそれに多くの時間とお金を費やしたことを知っています。もし私が間違っていなければ、意図は将来の製品開発のために実際に内部で使用することでした。

構築したいと思われるかもしれませんが、おそらくそうすべきではないようです。:)

プラガブルアーキテクチャへの大規模な投資が唯一の方法ですか？これらの問題をどのように管理し、どのような結果を目にしていますか？

編集： FogBugzはかなり堅牢なプラットフォームを構築し、それを使用して画面をまとめることで問題を処理したかのように見えます。それを拡張するには、ISearchScreenGridColumnなどのインターフェイスを実装するクラスを含むDLLを作成し、それがモジュールになります。多数の開発者がいて、数か月間作業したことを考えると、構築するのに莫大な費用がかかったと確信しています。さらに、その表面積はおそらく私のアプリケーションのサイズの5％です。

現在、Force.comがこれを処理する正しい方法かどうかを真剣に考えています。そして、私はハードコアASP.Netの男なので、これは自分自身を見つけるのに奇妙な立場です。

私は同様の問題に直面しました、そして私はそれをどのように解決しようとしたのかを説明します。

1. まず、「コア」ライブラリ、またはエンジンがあります。既に理解しているように、これは基本的にショーを実行します。フォームの動的なレンダリング、ユーザーとアカウントの管理、役割、名前の付け方、すべてのシステムに共通することを処理します。

2. システムのすべての部分はモジュール内に含まれています。モジュールには依存関係があります（依存する他のモジュール）。たとえば、「コア」システムには、セキュリティ（ユーザー、グループ、ロール、パスワードポリシー）、ロケール（翻訳、国、文化）、ファイルリポジトリ、電子メールなどがあります。各モジュールは、xmlファイルを使用して自身を定義します。xmlファイルは基本的に、スキーマ、テーブル、計算クラス、画面定義などを指定します。これらは、ファイルの日付が変更された場合にアプリケーションの起動時に読み込まれます。

3. 顧客固有のモジュールには、独自のxmlファイルと独自のDLLがあります。それに加えて、システムの残りの部分とそれに応じて透過的に機能します。既存のMVCビューを、カスタムコードとカスタムビューモデルを使用してカスタムビューに置き換えるだけです。

4. 顧客が既存の機能を拡張したい場合、xml / systemは、あるモジュールを別のモジュールから「派生」できるメソッドを提供します。新しいモジュールには既存のすべての機能がありますが、新しいDLLでのお客様固有の要件と、変更を行うことができる拡張XMLファイルがあります。警告は、彼らは実際にこのシステムの既存のフィールドを削除することはできませんが、それを拡張し、まったく新しいオブジェクトと機能を提供することはできます。

管理するバージョニングロジックとコードの層がたくさんあることは、Webアプリ/サイトに価値を追加するものではありません。また、何が起こっているのかを理解するためにより多くの脳力が必要であり、あなたがしていることの中核からあなたをそらします。

別のアドバイスをします。物事を複雑にするよりも単純にすることをお勧めします。

すべての人に同じ単一のコードベースを維持します。追加するすべての機能は、すべての機能です。機能ではなく、アイテムまたはストレージの数または定量化可能なもののみを制限します。その理由は、ストレージ、データエントリの数などのようなものを定量化するためにプログラムするのが非常に簡単であり、実際にユーザーがアプリに無理やり行くのを制限するほんの一握りのものに適用できるからです。いくつかの機能ロジックを実行する代わりに、アイテムの追加時にのみプログラムする必要があります。機能が他の機能に関連付けられている場合はどうなりますか？これをコーディングするのは非常に複雑になります。

私の答えを修飾するために、私は多くのクライアントのために持っているeコマースフレームワークを構築し、彼らのすべての特異性を維持しようとする難しい方法を学びました。最終的にチェーンを破り、eコマース用のマルチテナントである単一の管理Webサイトを作成しました。その後、Webサービス呼び出しからデータを取り込むWebサイトがあります。これにより、さまざまなテクノロジーのさまざまなチームがeコマースサイトに特定の機能を実装できるようになりますが、毎月同じインフラストラクチャで支払いを受け続け、彼らが何をしているのかは気にしません。機能ではなく、数字で使用を制限しています。その方法は簡単です。クライアントは独自のベンダーを選択してウェブサイトを構築することができ、私はこれらの決定に関与しなくなりました。

また、コンテンツ管理SAASのサブスクリプションサービスも提供しています。これは使用レベルによっても機能し、クライアントは必要に応じて独自のプラグインを追加できますが、チームにすべての機能を追加してもらいます。

これは、長い間頭を壁にぶつけてから、もっと簡単なものにつまずいたときの私の経験です。

何かが常に各クライアントに固有のものになる場合は、そのフレームワークを作成しないでください。それを最も単純な部分に分解して、フレームワーク部分がすべてに機能するようにし、残りを切り離して、個人用に拡張できるようにします。

私が取り組んでいるソフトウェア製品には、ユーザーの拡張性のための追加フィールドがあります。これらのフィールドの各データ項目は、アプリケーションのメインテーブルの既存の行にキー設定できます。たとえば、ソフトウェアに顧客が含まれ、各顧客に注文のリストがある場合、カスタマイズ可能なデータテーブルには、顧客テーブルと注文テーブルへの外部キーの列があり、そのうちの1つだけがnullにはなりません。そのテーブル、または各テーブルに1つのテーブルのカスタムフィールドがある複数のテーブル。

これは、ユーザー用の追加データを保存するためのシンプルでパフォーマンスの高い方法です。これらのフィールドの名前とタイプに関する追加情報を保存する必要があります。

これは、顧客のカスタムフィールドを対象としています。カスタム動作の場合、WebサービスAPIは拡張を許可します。

1）自分が所有するボックスで他の人のコードを実行するのは非常に難しい問題です。それらを信頼するか、責任を合理的に延期するか、コードを非常に重くサンドボックス化し、セキュリティに対する平均以上の献身をする必要があります。プラグインシステムがより多くの機能を使用できるようになると、プラグインシステムをセキュリティで保護することが難しくなります。サービス拒否（プラグインがリソースを過度に消費する）、情報漏えい（プラグインが他のテナントのデータにアクセスできる）などは、非常に現実的で面倒な場合があります。これらの問題またはそれを正しくするために多くの時間を持つ非常に有能な人々。

2）はい、モジュール性とカスタマイズ性は厳しいです。Strategyパターンなどが役立ちます（関数ポインターの空想的な名前。Javaでは、通常、クラスのユーザーがコードの動作をカスタマイズするために実装できるインターフェイスを宣言することで実装されます）これが機能するためのコード。

3）データ面では、これは有用なスキーマレスストレージの例の1つです。リレーショナルデータモデルを持っている場合は、別の顧客のための列のたくさんのテーブルを有する（はい、あなたがしている、ヌル値を許可する列の多くで終わる問題で悪い ;一つの理由は、それが正しい制約[すなわちを設定することが困難または不可能だということです無効なヌルの組み合わせを表示できない制約]）。顧客固有のテーブルを追加する（つまりusers、すべての顧客に対して有効なフィールドfoo_usersをusers保持しfoo_users、Foo固有のフィールドを持つ）正しい制約を簡単に設定できますが、RDBMSで適切に処理できない場合があり（結合の爆発、テーブルの数の制限などにより）、コードが見苦しくなります。

RDBMSにキーと値のストアを実装すると、データモデルのリレーショナル性が低下し、不快感が生じる可能性があります（つまり、リレーショナルデータベースは、リレーショナル系モデルに最適です）。NoSQLソリューションが全体的に問題に適合するかどうかはわかりませんが、ほとんどの実装のスキーマレス性が利点になる可能性があります。