OOAはエンティティレベルの仕様変更に弱くないか？

　ポリモルフィズムを使うとプログラムは綺麗に書けるけれど、保守しにくいのではないだろうか？

　仕様変更によるソースの修正範囲の大小は、仕様変更の中身がエンティティに及ぶのか、それともビジネスルールの修正だけなのか、によって決定されると思う。
　ビジネスルールの修正なら、修正範囲はそれほど大きくない。普通は、一つのクラス内で機能分割すればいい。
　
　しかし、エンティティそのものが修正されるなら、修正範囲は非常に広く、しかも修正範囲を調査するのに手間取る。
　普通は、修正対象のエンティティのgetXXX()/setXXX()がCallされているクラスを全て洗い出し、一つずつロジックを追いかけなければならない。そのロジック内部でポリモルフィズムが使われていたら、どのサブクラスで動いているのか、修正対象データはどのクラスへ委譲されているのか、更にソース解読に手間取る。
　ポリモルフィズムを使う利点は、新しいビジネスルールを追加しやすい所にあるが、エンティティそのものが変更されてしまうと、全てのサブクラスに影響が及んでしまい、ポリモルフィズムの利点が消えてしまう。
　
　他にも、HashMapやArrayListのようなCollectionクラスにエンティティのデータを詰め込んでいる時は要注意。状況によって、データがどの値で設定されているのか、理解しにくいから。
　Genericityが使えれば、詰め込むデータの型チェックが効くので、ソースは読みやすくなるが、それでも複雑さが解消されるわけではない。
　
　結局、プログラム群が一つのコンポーネントとして独立していない設計に問題があるのだが、そもそもビジネスルールはRDBに依存している事が多いため、エンティティに依存してしまう設計は避けられない。
　
　エンティティレベルの仕様変更は頻度は多くないが、サブシステムを新しく追加する時や従来のコード体系が変更される時に要件として出てくる。
　ビジネスルール層のOOAとRDB層のDOAは、設計思想として両立できるのだろうか？