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