システムに変更を加える際に大変な事とその解決策

結論

僕はシステムに変更を加える際に大変な事として下記の2つを認識しています。

ビジネスルールをドメインオブジェクトに表現し、実装する

システムに変更が必要なのは、ビジネスルールに変更が生じた場合と認識しています。

だからビジネスルール自体をドメインオブジェクトで表現する事で変更点の発見を楽にすると認識しています。

２つあると認識しています。

①ビジネルルールをドメインオブジェクトに表現し、重複が生じないように実装する

解決策とは言いつつ完全に重複が生じないよう実装するのは避けた方が良いと思っています。

以下、理由です。

完全に重複が生じないように実装すると、ビジネスの本質的には別のルールであるのに関わらず１つの箇所で定義する事が出来てしまう気がしてます。

完全に重複がやると本質的に別のルールなので将来的にそのルールの変更が起こると思います。

その変更が起きた際に、変更する箇所が多くなります。

この記事の汎用的な値オブジェクトがそれを指しています。

②ユースケースを定義し、ユースケース単位のテストコードを用意する

これ実践中で完全な検証が出来てません。結果が出たらこのブログに書きたいと思います。

考えは下記の通りです。

ユースケースを定義していると、変更を加えた際に全てのユースケースでテストを実施する事で他の機能への影響を知る事が出来る？