私は内部顧客向けのアプリケーションを開発しています。要件の1つは、他の組織に販売される可能性があるような方法で開発されることです。このアプリケーションは、寄付、寄付者、参加者、イベントを管理する資金調達組織向けの追跡アプリケーションです。認証用のプラグインアーキテクチャを開発し（承認は内部で処理されます）、外部ディレクトリから人口統計データを取得する必要があることはすでに知っています。
アプリケーションはASP.NET/C＃/ Linq /SQLServer上に構築されます。現時点では、代替データベースをサポートすることに積極的ではありませんが、将来、必要に応じて、さまざまなLinqドライバーを介してこれをサポートできると考えています。
これまでに作成したすべてのWebアプリケーションはカスタム実装であるため、プラグインや構成アイテムを介して対処する必要がある他の事項があるかどうかを知りたいと思います。任意の入力が役立ちます。
ありがとう。
「すべてを行う」フレームワークを作成しようとしないように注意してください。これは、多くの開発者が最初のいくつかの大衆向けソフトウェア アプリを構築しようとするときに犯すよくある間違いです。
すでに顧客がいて、アプリケーションの初期バージョンに資金を提供している可能性があります。この顧客が必要としているものをできるだけ多く提供する必要があります。そうしないと、マスマーケットについて考える前に失敗します。
アプリケーションを使用または購入する唯一の顧客であることを期待してください。過去に他のカスタム アプリを設計した場合とほぼ同じように、アプリケーションを設計します。
後で他の顧客にスケールアウトするために行う必要があるのは、ストックの asp.net の機能と機能にできるだけ固執し、できるだけシンプルで無駄のない状態に保ち、「高度な」機能をできるだけ多く削除することだけです。あなたが逃げることができるようにバージョン1.x。
1.x が証明の場になります。最初の顧客が必要とすることを実行し、それを非常にうまく実行するアプリケーションを提供するようにしてください。
成功し、1.x が最初の顧客の要件のほとんどを実際に満たしている場合、顧客のニーズのほとんどを満たすアプリケーションもあることがわかります。おめでとうございます。実行可能な商用市場アプリケーションの実現に向けて、すでにほとんどの道を歩んでいます。
注意事項：
複数のデータベース プラットフォームをサポートする必要が本当にありますか? 確かに、SQL Server よりも MySql を "好む" "一部の" 顧客がいるかもしれません。いくつかの構成オプションを変更するか、インストーラーで適切な選択を行うだけで、Oracle、MySQL、VistaDB、SQL Server などをサポートできる魔法の DAL を書きたくなるでしょう。しかし、実際には、この種の「プラットフォーム」の中立性は、設計を非常に複雑にし、利用する機能に厳しい制限を課します。プロバイダーの設計パターンのようなものを見ると、この種の設計はそれほど難しくないと思われるかもしれませんが、それは間違いです。実用的にアプリケーションを設計して、潜在市場の 90% に受け入れられるようにします。特にデータ アクセスに関しては、一般に、ASP.NET アプリケーションをインストールして実行する意思のある市場の 90% 以上が、SQLExpress または SQL Server を使用する能力があり、喜んで使用していると言っても過言ではありません。ほとんどの場合、複数のデータベースをサポートすることで追加の売り上げを得るよりも、SQL サーバーだけを設計することで、はるかに多くのお金と時間を節約できます。
オンライン管理ツールを使用して「すべて」を構成可能にすることは避けてください。たとえば、アプリケーション内のすべてのテキストを管理ツールで構成できるようにしたくなるでしょう。それは素晴らしいことですが、高価でもあります。開発に時間がかかり、アプリケーションの範囲を拡大して、他の方法では必要のない管理ツールをすべて含める必要があり、アプリケーションがより複雑になり、顧客の 90% にとって使いにくくなります。デフォルトのテキストは気にしません。
ローカライズを慎重に検討してください。大きな国際市場を持つことを考えていない場合は、1 つの言語に固執します。ローカリゼーションはそれほど難しくありませんが、コードのすべての側面を少し複雑にします...そして、あらゆるサイズのあらゆるアプリケーションで多くのことを追加します. 私の経験則は、最初の市場の言語のみをターゲットにすることです。アプリが他の市場に興味を持っている場合は、バージョン 1.0 からいくらかの現金を回収し、最初にアプリケーションが実行可能な市場であることを証明した後、バージョン 2.x に戻ってローカリゼーションを行います。ただし、複数の言語または文化に触れることがわかっている場合は、最初からローカリゼーションをサポートしてください。
バージョン 1.0 では、ドロップイン モジュールや凝ったサービス API についてあまり心配する必要はありません。再利用可能なフレームワークの経験が豊富な場合は、バージョン 1.0 でこの機能を使用できますが、この種のアーキテクチャの経験が不足している場合は、バージョン 1.x のこれらの機能に多くの時間を浪費するだけです。まだ間違っている可能性が高く、とにかくバージョン 2.x で再構築する必要があります。
アプリケーションが本当に優れたレポートを持っていることを確認してください。あなたが話している種類のアプリケーションの場合、これは、アプリケーションに市場があるかどうかを決定するものになります. 画面上で並べ替え/フィルター処理が可能なだけでなく、印刷も可能なきれいなレポートが必要です。あなたのお金と時間を門の外に置いてください。
最も重要なことは、完全に汎用的な方法で設計することです。つまり、クライアント固有の情報がハードコーディングまたは埋め込まれないようにすることです。
クライアント固有のものはすべて、メタデータを通じて構成可能でなければなりません。これを行う方法は完全にあなた次第ですが、主な方法は XML、データベース、またはプロパティ ファイルを使用することです。
このように設計すると、それぞれが独自の構成ファイルまたはデータを持つ任意の数のクライアントに販売される可能性があります。
オープン ソース テクノロジを使用している場合は、すべてのライセンス情報を 1 か所に保管することに少し時間を費やしてください。
Abarax は素晴らしい回答をくれました。ローカリゼーションを検討する必要があることを強調したいと思います - 話し言葉 (英語、フランス語、ドイツ語など) と組織の言語の両方について。すべてが彼らがいつも何かと呼んでいたものと一致しない場合、泣き言を言って泣き言を言うでしょう。