1 つのビジネスの複数のアプリケーションが存在するサイトを持っています。それらがすべて共有する複数のモデルがありますが、それぞれの機能には明確な違いがあります。たとえば、アプリの 1 つは、ユーザーが顧客のために製品の見積もりを作成できるようにします。もう 1 つのアプリはショッピング カートです。もう 1 つは製品の追跡用です。彼らは異なる聴衆のために異なることをしますが、どちらも製品とユーザーモデルを使用しています。
私の質問は、php や RoR の codeigniter のようなフレームワークを使用する場合、最適なアーキテクチャ上の決定は何かということです。
すべての機能を詰め込んだアプリケーションを 1 つだけ作成します。
複数のアプリケーションを構築し、共通のモデルとライブラリを 1 つの「マスター アプリ」で処理します (私の選択)。
ありがとう！
私たちも同じシナリオで作業しています。私たちのソリューションは .NET にありますが、少なくともほとんどの場合、テクノロジは心配する必要はありません。
共通のアプリケーション コンポーネントは、顧客アカウント管理、ショッピング カート、および認証モデルであり、3 つの異なるクライアント Web アプリケーションで共有されます。この問題を解決するために調査する方法がいくつかあります。目標は、すべての Web サイトで共通のコンポーネントを共有することです。
私たちが選んだアプローチは、すべてのアプリケーションが同じコードベースを共有することでした。3 つのアプリケーションすべてから Customer Account Management、Shopping Cart、および Authentication モデルを抽出し、最初に共通のコード ベースを作成しました。重要なのは、共通の共有モデルが、そのサービスを使用していたアプリケーションについての手がかりを持たないようにすることです。場合によっては、アプリケーションに固有のインジェクションを使用しましたが、ほとんどの場合、主要な共通コンポーネントは、どのアプリケーション データベースに書き込むか、またはアプリケーションごとに異なる共通のその他の設定のみを考慮していました。
欠点は、各アプリケーションが独自のバイナリを持っているため、同じ Web サーバーで実行すると、メモリにロードされるコードが、同じ共通モデルをロードする各アプリケーションの 3 倍の大きさになることです。しかし、これは私たちが事前に知っていた価格であり、現在のメモリは非常に安価です.
利点は、関心事の共通の分離があり、ある時点でアプリケーションが十分に異なる場合、それらは進化して別の動物になる可能性があることです。
もう 1 つのアプローチは、共通モデルを Web サービスに分離することです。ただし、このアプローチは、展開の観点からは少し脆弱です。
これが役立つことを願っています！
RoR については、アプリ間で共有される gem の作成を検討する必要があります。これにより、これらのコンポーネントのどの組み合わせをこれらのクライアントに使用するかを選択できます。
エンジンは、アプリケーション内のアプリケーションのようなものです - http://guides.rubyonrails.org/engines.html - このページでは、その使用方法の例を示します。