ナイーブなオブジェクト指向

私の書き方が悪くて誤解を受けた方がいるかもしれませんが、この話は、振る舞いを持たないDTOだとか、状態を持たない業務ロジッククラスの話とは、直接リンクしません。
私がいっているのは、データと振る舞いをカプセル化するという考えは、オブジェクト指向の重要なポイントですが、単純にデータに振る舞いを追加するのではなく、そこに、クラスは1つの役割だけを担うようにするという視点を必ず持つようにしましょうということです。
http://d.hatena.ne.jp/koichik/20041217#1103311826
で、書かれている通り、これは、ぜんぜん新しい話ではなくて、XPにおけるシンプルな設計もそうです。
デザインパターンも責任の分担の仕方をパターン化したものという見方もできます。
単一責任の原則を意識していないクラス設計は、ナイーブですよという話です。
確かに、レガシーという使い方は良くなく、ナイーブのほうが良いかも知れません。
問題は、ドメインオブジェクトに業務ロジックを追加するのが、ナイーブかどうかということです。
私の経験からするとドメインオブジェクトが複数の業務で使われるということは良くある話です。複数の業務の業務ロジックを1つのドメインオブジェクトに持たせるということは、単一責任の原則に違反しています。クラスを変更する理由が複数あるためです。
複数の業務で使われるドメインオブジェクトに業務ロジックを持たせるのは、単一責任の原則を考えると良くないということが分かるでしょう。
では、1つの業務でしか使われないドメインオブジェクトに業務ロジックを持たせるのはどうでしょうか。特に問題ないかもしれません。
しかし、最初は、1つの業務でしか使われていなかったけど、仕様変更や業務の拡大により、複数の業務で使われるようになるというのも十分考えられるケースです。
このような場合に、単一責任の原則に違反しているからといって、ドメインオブジェクトから業務ロジックを分離すると、このドメインオブジェクトを利用している業務にまで影響が及びます。自分に関係のない業務が追加されたのにもかかわらずです。
こう考えていくと、ドメインオブジェクトに業務ロジックを持たせるのは、多くの場合適切ではないということが分かってもらえるのではないでしょうか。
業務ロジックとは、ユーザに対して何らかの価値を提供するものとして、私は使っています。