シナリオ
毎晩、約 100 万件の顧客契約について一連の計算を実行します。各コントラクトは、約 10 個の製品のグループの 1 つに関連付けられており、実行される一連の計算のバリエーションを使用する場合があります (ただし、全体の流れはほぼ同じです)。特定の製品のすべての契約は、特定の夜に同じ計算セットを使用します。分布は不均一ですが、最小の製品で数千から最大の製品で数十万に及びます。
時間が経つにつれて、新しい同様の (ただし同一である可能性は低い) 製品が追加され、既存の製品は、採用されているアルゴリズムにバリエーションを導入することによって調整される場合があります。(ちなみに、コードを変更することなく、アルゴリズムをパラメトリックに変更できると思います)。
これをサポートするために使用するコア「エンジン」は、製品開発と生産の両方に適用できる必要があります。後者は、何を受け入れるか、変更が一般的にどのように管理されるかについて非常に慎重な運用担当者によって管理されます。
アーキテクチャを検討する際に、私はOpen-Closed Principleに強く惹かれます。
ソフトウェア エンティティは、拡張に対してはオープンである必要がありますが、変更に対してはクローズされている必要があります。
C# での実装を計画しているので、関数をコアの外部で定義し、テキスト形式でロードし、現在のバージョンの製品定義の管理下にある製品の実行の開始時にコンパイルすることを規定することを検討しています。 . これらの各コンポーネントは、アプリケーションのコンパイル済み要素で定義されているインターフェイス (または同等のもの) を実装するクラスにコンパイルされます。リグレッション テストの範囲が大幅に縮小されるため、運用の観点からはプラスになると楽観視しています。
質問）
これは理にかなっていますか？潜在的な落とし穴について賢明なアドバイスを提供できる人はいますか?
私は依存性注入を再発明していますか?たとえば、毎回新しい DLL を提供することで、定期的な変更を提供することをお勧めしますか? もしそうなら、それは私たちの毎日の製品開発プロセスをどれだけ悪化させますか?
それとも、よりアジャイルなアプローチを取り、1 つの製品をエンド ツー エンドで構築し、他の製品を順番に追加して、リファクタリングによってどのようなアーキテクチャが出現するかを確認する必要がありますか?
あなたがまだ私と一緒にいるなら、あなたの忍耐に感謝します...