顧客固有の実装はどのように処理できますか？
顧客固有の実装をどのように処理できますか。したがって、たとえば、カスタムには、データを表示するための別の方法、別のモデル、または別のロジックが必要です。
[〜＃〜] hmvc [〜＃〜]について読みましたが、それをサポートするフレームワークが見つかりません。顧客に固有のブランチを作成するか、プロジェクトをフォークすることで問題を処理する必要がありますか？それとも、バージョン管理とは何の関係もありませんか？
あなたは本当に顧客固有のブランチ/フォークを望んでいません。複数の主要なブランチを維持するのは面倒です。場合によっては、それらが本当に必要になることもあります（たとえば、リリースを安定させたり、古いバージョンをサポートしようとしている場合）が、通常はそれらの数が少なく、何をプッシュするかという問題があります。関係なく解決する必要があります。ここでは、顧客ごとのブランチについて説明します。これは、顧客を維持している限り維持する必要があり、各新機能をこれらの各ブランチにマージします-おそらく異なるの競合同じコミット...
まず、問題を再考することをお勧めします-本当にクライアント固有の機能が必要ですか？確かに、一部のクライアントは機能を要求するのに十分な大きさおよび/または重要であり、それらを開発するために時間とお金を投資する必要があります-しかし、これらのクライアントはこれらの機能の著作権を所有しておらず、とにかくそれらをテスト、文書化、および維持する必要があります-では、これらの機能を製品の一部にしないのはなぜですか？あなたの他の顧客はこれらの機能を持つことから利益を得るでしょう、そしてあなたはそれほど多くの主要なブランチを維持する必要がないことから利益を得るでしょう。
何らかの理由で、これらの機能を要求したクライアント以外のクライアントに出荷できない、または出荷したくない場合は、プラグインアーキテクチャを検討してください。一般的な方法は、スクリプト言語エンジンをホストするか、APIを提供して、プラグインを外部プロセスとして実行することです。顧客固有のコードは、あなたまたは顧客のいずれかによって開発および所有されるプラグインになります（pro-プラグインの微調整についてはあまり気になりません。con-プラグインアーキテクチャに関するサポートについては気になりません）。プラグインは、メインプロジェクトとは別に、独自のコードベースを持ちます。プラグインメカニズムの下位互換性に注意を払う限り、プラグインの保守はそれほど難しくありません。
プラグインはプラグインアーキテクチャによって制限されることに注意してください。ただし、メインプロジェクトに機能を配置できない場合でも、通常、プラグインとして実装するために必要な最小限のプラグインAPI変更を配置できます。