ドメインモデル

「抽象クラスを継承してエンティティ特有のビジネスロジックを実装する」ってことは、そのエンティティは貧血でないドメインオブジェクトってことでしょうか。
SAStrutsの機能リファレンスでは「複数のアクションから共通に使われるような機能は、サービスクラスで実装すると良いでしょう」との記述もありますが、サービスとエンティティに実装するロジックの切り分けは、やはり粒度に応じてってことになるのでしょうか。

SAStrutsでは、エンティティ特有のビジネスロジックは、そのエンティティに持たせることを推奨しています。ということは貧血症(?)ではないオブジェクトだということです。しかし、肥満症(?)なわけではありません。SAStrutsのドキュメントにはこうかかれています。

ビジネスロジックは、エンティティに 定義します。ビジネスロジックと間違えやすいのが、データアクセスのロジックと、 エンティティの関連をたどる(部署のエンティティから関連先の従業員のエンティティをみにいくこと) ような複数種類(部署と従業員)のエンティティにまたがるようなロジックです。

複数種類(部署と従業員)のエンティティにまたがるようなロジックは、制御ロジックとして、アクションやサービスに持たせます。
複数種類のエンティティにまたがるようなロジックをエンティティ持たせようとすると、どのエンティティに持たせるのかに正解はなく、人によってばらつきます。しかし、制御ロジックと捉えて、アクションやサービスの持たせれば、迷うことはありません。
エンティティは、粒度の小さいオブジェクトなので、そのエンティティに閉じているメソッドのみを持つのが良いと思っています。
前といってることが違うジャンって。いいんです。道具がかわれば、それをできるだけ生かした使い方をすべきだから。