Separation of Hotspot

ホットスポット(変更の起きそうな部分)を分離する。

これは、変更に強いシステムを作る上での最も基本的な原則です。例えば、あるクラスが安定している部分と、頻繁に変更される部分で構成されていたとします。このクラスに変更が入るたびに、安定している部分も影響を受ける可能性があり、そのクラスのテストもすべてやり直す必要があります。
そのクラスの頻繁に変更される部分を別のクラスに分離してしまえば、もとのクラスは安定して修正が入ることはなくなります。
極めてあたりまえのことを言ってるように思われるかもしれませんが、実はあまり守られてはいないと思います。その原因は、「関連のあるデータと振る舞いを1つにまとめることがオブジェクト指向だ」とする強い思い込みです。頻繁に変更される振る舞いを別のクラスに分離すると、オブジェクト指向的ではないと思ってしまうのでしょう。
「関連のあるデータと振る舞いを1つにまとめること」は、オブジェクト指向の基本であり、まず最初に実践して欲しいことですが、それはあくまでも基本であり、例外ケースがあります。その例外ケースが、Separation of Hotspotなのです。そして、ほとんどの業務アプリケーションにおいては、ユーザの要件は、変更されやすいホットスポットなのです。
リッチなドメインモデルにおけるドメインオブジェクトのメソッドは、ほとんどがユーザの要件を実現するためのものであり、ホットスポットです。ホットスポットは安定している部分から切り離した方がいいのです。ドメインオブジェクトに残るメソッドは、ユーザの要件に関係のないものになるでしょう。
サブジェクト指向もいいかたは違っていますが、同じ方向性だと思います。
http://www.atmarkit.co.jp/fdotnet/softfactory/softfactory04/softfactory04_03.html
そして、ユースケースはアスペクトだといっているAOSDもたぶん、そうです。
リッチなドメインモデルは、変更の多いシステムには向かないということが、だんだん認識されてきているのでしょう。
その解決策の1つとして、ドメインオブジェクトから業務ロジックを切り離し、その業務ロジックをDIContainerで管理するという方法もあります。
リッチなドメインモデルに「あこがれ」を持っている人もいるようですが、「変更の多いシステムには向かない」ということをあらためて指摘しておきます。