アプリを入手できる各ビジネス市場（国や州）ごとに要件がわずかに異なるアプリを開発しています。それは一般的な状況のようですが、このシナリオのコード/モジュールの構造化に関する良い記事を見つけることができないようです。
これはC＃アプリであり、戦略パターンとテンプレートパターンの間で議論していますが、フォルダー構造と命名規則の考慮事項もあります。各州の個別のプロジェクトはすぐに管理できなくなるようです（たとえば、5つのコアサービスX 50州のカスタムプロジェクト）= 250プロジェクト!!）おそらく、サービスごとに1つのカスタムプロジェクトが、州ごとにサブフォルダーに編成された専門化を処理していますか？
回答:
単一のアプリを用意し、適切な構成ソリューションを設計します。
JacquesBはこれをほのめかしますが、もっと強く述べたいと思います。これは、50以上のバージョンのコードベースを開発するのではなく、構成によって行う必要があります。それ以外のものは、めちゃくちゃ管理できなくなります。
単純な構成パラメーターでは処理できない複雑な要件がある場合は、より複雑な構成ソリューションを設計します。
構成には、ロジック要件を定義する単純なスクリプト言語が含まれている場合もあります。それは大丈夫です。重要なのは、「構成」をアプリのコードベースから明確に分離する必要があることです。
そうしないと、バグの特定や修正などが混乱します。ロケール固有のバージョンに加えて通常のバージョン管理を使用すると、フィールドには何百ものバージョンが存在します。また、バグがロケール固有のコードと基本コードのどちらに関連しているかを簡単に判別することはできません。
エッジケースについて今考え始めてください。
これは、信じられないほどのコストがかかる、誤った仮定を行うリスクが高い状況です。「各アプリユーザーは、1つのロケール内でのみ動作する必要があります」など。本当？このような問題については、できるだけ早く真剣に考えてください。
それは本当に何が違うかによる。それは純粋に構成（例：税率）で表現できるものですか、それとも本当に各州に個別のコードロジックが必要ですか？構成によって純粋に処理できるほど、より優れています！
あなたは、最も可能性の高い状態で別々のコードを必要としません。たとえば、一部の市場は払い戻しを発行し、他の市場は交換を発行するとします。これはまだ、テストする必要がある2つのコードパスです。次に、どのパスをどの状態に使用するかを構成で示すことができます。これは、状態ごとに個別のコードを作成するよりもはるかに優れています。それでも、50を超える2つのコードパスをテストするだけで済みます。
50の状態のそれぞれに対して個別のコードを記述する必要があると感じた場合、おそらくそれは間違っています。状態ごとに個別のプロジェクトを作成したり、構成セクション以外の「50の異なる」プロジェクトを作成したりしないでください。
私はそのようなプロジェクトでいくつかの実際的な経験があり、少なくともいくつかの一般的なガイドラインを提供できます。
JacquesBは、構成があなたの親友であることは間違いなく正しいです。その構成をファイルとデータベーステーブルのどちらに置くかは、スタイルの選択です（ただし、構成ファイルを使用しますが、いったんサービスをセットアップすると、あまり変化しないことを確信しています）。
あなたがおそらく慣れているものよりもはるかに間接的に見えるコードを期待してください。「次はこれを行う」と言う代わりに、「次に何をするかを構成に尋ねてから、それを実行する」と多くの場所があります。これは開発の頭痛の種になる可能性がありますが、それに慣れるでしょう。
「これらはおそらく誰もが望んでいる共通の要素であり、これらは個々の州のために手動で設計されたオーダーメイドの要素です」の構造をお勧めします。そのために、デフォルトの機能を正しく識別することは、コードが将来どのように簡単に/ひどく動作するかについての大きな部分になるでしょう。構成可能である必要があると思ったものよりも多くのものを知ったら、リファクタリングを行う準備をしてください。
カスタム要素からのエラーメッセージは、それらがどこから来たのかを正確に識別できることを常に確認してください。膨大な数の異なる実行パスがあるため、デバッグは何に関係なく失敗します。イースターエッグハンティングの量を減らすためにできることは何よりも価値があります。
時間をかけて優れた自動テストスイートを作成します。本当に良い自動テストスイート。これは常に良い習慣ですが、あなたにとって、それは文字通り成功と失敗の違いを意味するかもしれません。繰り返しますが、これは非常に多様な実行パスです。一般的なコードに変更を加えると、予期しないブランチのバタフライ効果のバグに対して脆弱になります。それらが本番環境に入る前に、それらのバグをキャッチする必要があります。
ourproject.calculations.taxデフォルトのようなものと、ourproject.florida.calculations.taxフロリダ州の法律によって強制されたカスタムmod（ある場合）のようなもの。その市場名をどこに置くかは議論のポイントですが、特定の市場がどのようなカスタマイズを強いているかを簡単に確認できるようにしたいと思います。
configはすべての問題を解決するのに役立つわけではありませんが、新しい問題を作成する可能性があります。
私の経験でこれまでで最高の方法は、すべてまたは任意の状態（テナント）を処理できるマルチテナントソリューションを作成することです
これには構成が必要です。つまり、州ごとの消費税率だけでなく、条件付きコードLegalMethodOfCalculatingWorkingHoursA vs B
アプリがホストされている/オンラインの場合は、条件付きコードにマイクロサービスのアプローチをとることができますが、オフラインのソリューションでは、すべてのオプションモジュールをバンドルしてそれらから選択する必要があります
消費税や、単一の州でのみ使用されるクレイジーな法則など、すべての州で再利用されるいくつかのモジュールがあります。また、法律は時とともに変化することもわかります。使用されるモジュールは、単一の状態内で時間によって異なります
したがって、状態ではなく機能による名前付けを使用します。