私は、既存のレガシー ソフトウェアを書き直すプロジェクトに取り組んでいます。従来のソフトウェアは、主に SQL データベースに対する CRUD 操作 (作成、読み取り、更新、削除) で構成されています。
CRUD ベースのコーディング スタイルにもかかわらず、レガシー ソフトウェアは非常に複雑です。このソフトウェアの複雑さは、問題領域自体の複雑さの結果であるだけでなく、貧弱な (そして通常は非常識に近い) 設計上の決定の結果でもあります。この不十分なコーディングにより、データベース内のデータの整合性が失われています。これらの整合性の問題は、関係 (外部キー) だけでなく、単一の行内の整合性にも関係しています。たとえば、列「x」の意味は、列「y」の意味と完全に矛盾しています。(質問する前に、答えは「はい」です。私は問題のドメインを分析し、これらの列の意味と目的を正しく理解しており、元のソフトウェア開発者よりも優れているようです)。
代替ソフトウェアを作成するとき、主にドメインの複雑さのために、ドメイン駆動設計とコマンド クエリ責任分離の原則を使用しました。たとえば、書き込みモデルで不変条件を適用する集約ルート、「クロス集約」整合性チェックを実行するコマンド ハンドラー、さまざまな画面に適した方法で意図的に非正規化されたデータをクエリするクエリ ハンドラーなどを設計しました。
新しいデータを入力する場合、正確さと使いやすさの点で、代替ソフトウェアは非常にうまく機能します。その点では成功です。ただし、既存のデータには整合性の問題がたくさんあるため、既存のデータに関係する操作は、例外をスローして定期的に失敗します。これは通常、コンストラクターに渡されたデータが集計の不変条件に違反しているため、リポジトリから集計を読み取ることができないために発生します。
この「ルールを破る」レガシーデータをどのように処理すればよいでしょうか。古いソフトウェアは、ほとんど検証なしで実行されたため、この点で問題なく機能しました。この検証の欠如により、経験の浅いユーザーが無意味なデータを入力するのは簡単でした (また、経験豊富なユーザーは、その「特異性」を何年にもわたって理解しているため、非常に価値のあるものになりました)。
データ自体は非常に重要なため、破棄することはできません。私に何ができる？整合性の問題を整理してみましたが、これでうまくいく場合もあれば、ほぼ不可能な場合もあります (たとえば、元の開発者がデータを保存しないことにしたため、データがデータベースから完全に失われているなど)。データの整合性に関する問題の数は膨大です。
私に何ができる？