DTOと振る舞い

くーすにおけるDTOは、(基本的には)エンティティ(ドメインオブジェクト)を継承して、プレゼンテーション層に必要な項目を追加したものです。
正規化されたテーブルを扱いやすいように非正規化するようなものだと考えても良いでしょう。
カプセル化の話で言えば、もともとpublicなデータを格納するのが目的なので、カプセル化うんぬんも関係ありません。
1つのエンティティに閉じている振る舞いなら、そのエンティティに持たせても良いでしょう。しかし、複数のエンティティにまたがる振る舞いは、どのエンティティに持たせるのが良いのかは、あいまいになりがちです。そして、業務アプリケーションにおいては、複数のエンティティにまたがる振る舞いが圧倒的に多いのではないかと思います。結局、どのエンティティがどの振る舞いを持つのかということは、絶対的なものではなく、人によってバラバラになります。
ここで、視点を変えて、システムを保守することを考えてみましょう。
ある業務機能に仕様変更が入った場合、影響が有りそうな部分のソースコードを調べて影響範囲を見極めます。このとき、ある業務機能の振る舞いが複数のエンティティに分散していて、しかも、1つのエンティティに複数の業務機能の振る舞いが定義されている場合、影響範囲の見極めは結構めんどうな作業になります。エンティティに振る舞いを持たせた場合は、1つのエンティティに複数業務の振る舞いが定義されることは良くあることです。
業務機能ごとにクラスを作成し、そこに振る舞いを持たせるとどうでしょうか。仕様変更が入った場合でも、その業務機能のクラスに振る舞いが集められていますから、影響範囲の見極めは簡単で、しかも、ある業務機能の変更がべつの業務機能に影響を与えることはありません。
もう一度、エンティティに振る舞いを持たせる話に戻りましょう。複数のエンティティに関連する振る舞いがある以上、どのエンティティがどの振る舞いを持つかという話は、あいまいであり、人によってまちまちになります。
このようにあいまいになるんだったら、業務機能に振る舞いを持たせるという風に決めてしまえば、あいまいさはなくなり、保守も容易になります。
データ(状態)はDTOが持っていますから、業務機能の振る舞いを持つクラス(業務ロジッククラス)は、自然とStatelessになるのです。