複数のエディションを持つアプリケーションを作成するためのデザイン/アーキテクチャーパターンがあるかどうか不思議です（Windowsのホーム、スタンダード、アルティメットエディションなど）。複数のエディションを持つアプリケーションのデザインパターン
主なアイデアは、ユーザーが持つエディション（基本、高度、完全）に応じて、ユーザーに異なる機能を提供するアプリケーションを作成することです。誰かがプラグインの使用を提案しました...これは良いアプローチですか？
ありがとうございます！
多くのオプションがあります。
概念的には、最も簡単なことは、可能な限り再利用する3つの異なるアプリケーションを構築することです。つまり、共有機能を提供する「エンジン」と、エンジン上で実行される3つの別々のアプリケーション（「基本」、「上級」、「完全」）を持つことができます。これは、MSオペレーティングシステムの味のようなものです。エンジンは基本的なオペレーティングシステムであり、異なるエディションには、エンジンの上に構築されたさまざまなアプリケーションが含まれています。
このルートの利点は、概念的に有効な製品を作成できることです。エディション間に多くの依存関係がなく、「フル」エディションが「基本」エディションの機能を含むことを決定していない場合意味をなさない、彼らはその依存関係を壊すことを心配する必要はありません。
第2のモデルは、1つのアプリケーションを構築し、ビルド時または実行時のいずれかの設定によってその動作を制御することです。例えば、 "ifdef"は、単一のCコードファイルが異なるオペレーティングシステムを対象とすることを可能にします。同じSQLデータベースエンジンの異なるフレーバでサポートされているプロセッサの数は、実行時設定によって制御される可能性があります。
これには、管理する単一のコードベースがありますが、エディション間の結合が非常に緊密であり、すぐに管理できなくなるという利点があります。
多くのアプリケーションで「プラグイン」モデルが使用されています。これは最初のオプションのバリエーションです。フレームワークアプリケーションを最初に構築する必要があり、各エディションの機能はフレームワークの機能によって制限されます。多くのゲームはこのように設計されており、バージョンの違いは基本的にはどのプラグインがゲームに同梱されているかによって異なります。
これはアーキテクチャ上非常にきれいですが、プロジェクトに本当のリスクをもたらします。賢明な開発者はすべてフレームワークで作業したいと考えています。フレームワークの開発者が実際の要件が間違っていると思うと、間違った製品をサポートする素晴らしいフレームワークが得られます。また、フレームワークは、ロギングやプラグイン構成などのコンピュータサイエンスの問題に焦点を当てる傾向があり、実際のビジネス上の質問にはあまり集中しません。私はこれを最初に見てきました、そして、それはちょっと悲惨でした。
無制限の時間と予算を持たない限り、最初のリリースが出たら、オプション1から始まり、オプション3に進化します。
私はパターンがこの状況であなたを助けないと思います。
これらのバージョン（基本、高度、完全）は、さまざまなモジュールセットで異なります。あなたがあなたのプログラムで良いモジュール性をサポートしている場合は、モジュールのセットをセットアップできる各バージョンに対応するビルドスクリプトだけを分離することができます。
プラグインは私がやる方法です。 – Glenner003