私が働いている会社には、保険会社からの要求に対応する修理会社向けの ERP ソフトウェア、またはより適切なホーム インシデント管理アプリケーションがあります。
標準からコピーされ、特定のニーズに合わせてカスタマイズされた当社のアプリケーションを使用している多くの修理会社があります。
それを更新してスケーリングするのは悪夢です!
これを最適化するための良いアプローチについて知りたいです: 各企業の継承クラスを持つ同じアプリケーション インスタンス? インターフェイスはここに収まりますか？異なるサーバーで集中化されたアプリケーションをどのように扱うことができるでしょうか? すべてに対して 1 つのサーバーだけを使用することは望ましくありません。
構成可能性と拡張性のために、Java、Spring、および OO を使用しています。通常、アプリケーションにはプロパティを含む「構成」テーブルがありますが、通常、構成可能性の必要性は、プロパティが簡単に構成できる範囲を超えています。
これはまさに、OO プログラミング言語、コンテナーの完全な制御、および構成/依存性注入のための Spring や ORM マッピングのための Hibernate などの強力なフレームワークが本領を発揮するドメインです。
これらすべてを PHP で「試す」ことができますが、すべての言語で 20 年以上の経験があり、軽視するつもりはありません。本格的な製品の場合、本格的な言語への移行を検討する必要があるかもしれません。
実際に何をする必要があるかについて：
そのための構成テーブルと管理 UI。これらは基本的にキーと値のプロパティであり、可変性が必要な場合に定数ではなくアプリケーションで使用します。これらをキャッシュすることはパフォーマンスにとって不可欠であるため、ここではサーバーレベルで Web アプリケーションを制御することが重要です。
戦略パターン。税金の計算、請求書の作成、外部システムとのインターフェースなどのアルゴリズムは、プラグ可能で構成可能な戦略として実装されます。https://en.wikipedia.org/wiki/Strategy_pattern
XML Bean 構成/依存性注入。展開とアルゴリズム構成用。このレイヤーは戦略を選択、作成、構成し、顧客の要件に適したアルゴリズムを選択してパラメーター化できるようにします。これがモジュール性であり、顧客間でほとんどのコードベースを共有できますが、ここで必要な違いを差し込むことができます。Java では、Spring を使用します: http://docs.spring.io/spring/docs/2.5.3/reference/beans.html
さまざまな顧客の要件に合わせて機能し、構成できる実際のソフトウェア製品を構築することは困難です。堅固なプラットフォーム、実際のツール、および適度な設計スキルが必要です。
構成可能性と戦略に直接関係しない別の問題は、マルチテナントアプリケーションです（@Leeが言及していたもの）。これは、アプリケーションが複数の顧客を異なる設定で同じサーバーから同時に実行する場所です。（私は最近、そのようなアプリの主要なインフラストラクチャ作業、アーキテクチャ、およびアップグレードを行いました）。ただし、これは別の問題であり、さらに複雑であり (ただし、やや複雑です)、このトピックで説明する必要はありません。
私の経験では、Java と C# は高速で信頼性が高いのに対し、PHP は低速で信頼性が低く、セキュリティの脆弱性を助長する傾向があります。私は、高度な要件、システム統合、高性能機能を備えた多くの主要なアプリケーション (産業、政府、金融、ソフトウェア製品) を、コンパクトなものから中規模のアプリ、大規模なアプリまで行っています。そのため、私はマルチカスタマー製品を提供する方法と、パフォーマンスが高く信頼性の高いアプリを成功裏に提供できるプラットフォームを熟知しています。