「ビッグデータ」設定のSRP
次のようなコードベースが機能しています。
- 何千もの小さなファイルを（低）取り込みます。これらの各入力ファイルには、約5万の「マイクロアイテム」が含まれています
- 次に、これらの「マイクロアイテム」をクラスター化して「マクロアイテム」を見つけます。
- 「マクロアイテム」は、他のさまざまな重要なビジネス計算および分析への入力になります。これらのマクロアイテムは、私たちの組織の生命線です。
- このすべては、ApacheのCrunchライブラリ（Hadoopによってサポートされている）を使用して機能しますか？
上記のステップのいくつかは、クランチなしでは実行が難しいことは事実です。特に「クラスタリングの問題」は、1台のマシンで厳密にメモリ内で実行することはおそらく不可能です。クラスタリングのステップで考慮する必要のある項目が多すぎます。
また、データが多すぎるため、規模に合わせて構築されていないソリューションは持つ価値がないと主張することもできます。
そうは言っても、コードベースがSRPを左右に壊しているような気がします。たとえば、生の入力ファイルを解析するアルゴリズムは、Crunchの「doitenmasse」クラスから簡単に分離することはできません。つまり、入力ファイルが1つしかない場合、本格的なCrunchジョブを実行しないと解析できません。さらに、「クラスタリングアルゴリズム」や「重要なビジネス計算」に簡単にアクセスしたり、テストしたりすることさえできません。
これはビッグデータスペースで一般的な問題ですか？大量のデータがある場合、SRPはウィンドウから飛び出しますか？
このコードベースを2つのプロジェクトAとBに分離しようとするのは妥当な目標ですか？プロジェクト（A）は、解析アルゴリズム、クラスタリングロジック、および重要なビジネス計算を定義して適切にテストし、プロジェクト（B）はプロジェクト（A）に依存し、Crunchを使用してこれらすべてを大規模に実行すると想定しています。
厳密な分離を提唱したい理由の一部は、すべての非分散計算でのテストを大幅に改善することです。分散クランチジョブが失敗し、その理由を特定するのが難しい場合、それは恐ろしいことです。
SRPは、モジュール（またはライブラリ）、パッケージ（または名前空間）、クラス、および関数レベルで発生します。
これが意味することは：
- ライブラリには、変更する理由が1つあります。たとえば、ネットワークライブラリを構築します。変更する正当な理由には、新しいプロトコルのサポート、既存のプロトコルのバグの修正が含まれます。変更する無効な理由：クライアントまたはサーバーのエンドポイントが変更されます。
- 名前空間には、変更する理由が1つあります。それは、ネットワークライブラリをさらに一歩進めることです。 MyCompany.Networking.Http名前空間は、HTTPの実装の変更に関してのみ変更する必要があります。 FTPやSMTPに関係するべきではありません。HTTPへの変更、実装のバグ、またはプロトコルの新しいバージョンをサポートするためにパッケージを変更するだけです。
- クラスに変更する理由は1つだけです。MyCompany.Networking.Http.HttpClientは...よくわかります。
Crunchがシステムが操作をスケーリングするために使用する単なるユーティリティである場合、そうです、操作自体はcrunchとは別に実装する必要があると私は主張します。
あなたが言及した分割は完全に論理的に理にかなっています。オペレーション自体は、ビジネスロジックの変更をサポートするためにのみ変更するようにSRPに拘束されます。コーディネーターは、あなたのオペレーションとクランチの間のオーケストレーションを行います。 （必要に応じて、大規模な処理にクランチを使用するかどうかの変更からコーディネーターを保護できますが、SRPの経験則では、変更のクラスが適用可能になったときに保護します。タスクエンジンの切り替えはスリムからゼロになります。抽象化を提供するため、あまり効果はありません。
私はJavaプログラマーではありませんが、あなたが説明した問題はもっと一般的です。
現在、100％信頼できるわけではないソリューションがあります。私が理解したことから、あなたは維持それをする必要があると理解しました。 技術的負債「回復セッション」中に経験する苦痛を軽減するために返済したいものがあります。
コードベースから単一の部分を抽出してみてください。通常、コードを操作した後は、コードをよりよく理解し、何をリファクタリングするかについてより自信を持って感じることができます。コードのすべての行を分離することはあなたにとっての勝利です。
後で、同様の機能のパターンまたはクラスターが表示されます。それらを1つのクラスにマージし、DIとして提供します。