DDDで設計していると エンティティ と エンティティ の間に関連があり、その 関連に関するドメインの振る舞い と言うものが出てきます。
(中略)
このような振る舞いをどのコンポーネントの実装するか？が悩ましかったりするのですが、 ここで紹介する "ロールオブジェクト" を導入することでスマートに設計・実装することができます。
なお、ここで言う「スマート」とは、具体的にはアプリケーション層のコードをユースケース記述のように書けることを意図しています。 アプリケーション層のコードをユビキタス言語を使ってユースケース記述のように書くことができれば、ドメインの知識とコードをより近づけることができると思います。
Userクラスに責務が集中し過ぎるというありがちパターンを避ける方法として、ロールオブジェクトを導入する。
Serviceクラスとして書くのは、単なるトランザクションスクリプトになってしまいDDDの旨味が消失するのでNG。
ので、エンティティとエンティティの関連を現す概念クラスをロールオブジェクトとして定義して、そいつに責務（ドメインロジック）を持たせる。
すると、「スマート」な設計・コードになると。
よさそう。
アプリケーションのユーザー概念を表す User モデルは本質的に責務が集中しがちだし、ロールの分離も難しそうな気がする。例えば、あるサービスの利用者を User モデルとして表現したとき、 User が行うユースケースはサービスが提供する機能のほぼ全てになる。それらを全て User モデルの責務とすると神オブジェクトアンチパターンもいいところである。
したがって、GRASPパターンの純粋架空物めいたオブジェクト（モデル）は必要ではあり、それは Task クラスとして独立されるべきであるように思える。