ASP.NET MVC 5モジュラーWebアプリケーションアーキテクチャ？
私が現在雇用されている会社は、私たちのさまざまなアプリケーションのアーキテクチャ上の決定に苦労しています。現在、共通の部分を持ついくつかのアプリケーションがあります（カレンダーモジュールのように考えてください）。これまで、他の既存のアプリケーションからコードをコピーし続けましたが、将来的には、アプリケーションをよりモジュール化された設計に進化させたいと考えています。
上の図でわかるように、アプリケーションごとに異なるバージョンのモジュールを使用することができます。
考えられる解決策を検討しています。
- モジュールをインストールできるコアアプリケーションフレームワークを構築します。これを実現するためのNugetのようなツールを考えています。
- すべてのモジュールが含まれている（= 1つのコードベース）1つのアプリケーションを構築しますが、顧客は自分のためにアクティブ化された機能のみを取得します。ここでは、バージョン管理に関するいくつかの問題が発生することが予想されます。
これに関する提案はありますか？この問題に苦しんでいる最初の会社になることはできませんか？すべてのアプリケーションは、RazorテンプレートまたはJavaScriptテンプレート（knockout.js）で構築されたASP.NET MVC 4/5Webアプリケーションです。すべてのアプリケーションはMicrosoftAzureにデプロイされており、ビルドスクリプト（MSBuild）、CIサーバーに関する社内の幅広い知識があります...
モジュールごとに個別のプロジェクト/アセンブリを用意し、それをNugetパッケージとして提供することは間違いなく良い戦略です。
利点：
- 複数のバージョンを維持およびリリースできます。クライアントが異なれば、バージョンも異なります。
- Nugetでサポートされている最新または特定のバージョンのインストール。これは、アプリAの開発者がモジュールAの2.0バージョンをターゲットにでき、アプリBの開発者が1.0をターゲットにできる開発中に役立ちます。
- バージョンごとに個別のブランチを持つ単一のソースベース。 1.0リクエストを使用しているクライアントは、変更がリクエストされた修正だけでブランチ1.0からコードを取得します。
- 各モジュールは、個別にリリースまたは更新できます。
課題：
開発デバッグ中に、Nugetを使用してインストールされたアセンブリコード。 Nugetは組み込みでサポートしています。私たちの場合はそれを達成しました（フレームワークは複数のプラットフォームで使用されています）。
モジュールコードで必要なコード変更（バグまたは新機能が必要）。これは注意が必要です。
オプション1：同じ開発者が先に進んでその変更を行い、新しいパッケージを作成して、アプリに新しいバージョンをインストールします。重要なコードであるため、変更を承認する必要があります。
オプション2：フレームワークコードの問題または変更要求を修正する責任がある指定されたチーム。
プラグインアーキテクチャを使用して、アプリケーションを構成するさまざまなモジュールをプラグインとしてビルドしてから、すべてのアプリケーションに必要なモジュールを単一のコードベースとしてビルドすることもできます。この場合、特定のユーザー向けのコンポーネントをインストールするには、プラグインを追加または削除する必要があります。多くの大規模なプロジェクトでは、コピーと貼り付けが減り、再利用が増え、開発がスピードアップするため、この特定のアーキテクチャを利用できます。 nopcommerce オープンソースプロジェクトで、それがどのように行われるかを確認できます。