どのクラスに処理を記述すべきか？

1つユースケースに閉じていることは、すべてActionに記述し、複数のユースケースで使われるものをLogicに分割するのがシンプルでわかりやすいのではないかと、そう思ったわけです。

＜＜中略＞＞

追記2:コメントへの回答ですが、ユーティリティは、staticメソッドで構成されるやつは、utilのパッケージ。ActionにDIするやつは、logicパッケージでいいと思います。どっちでもないユーティリティもutilパッケージですね。

Entityについては、SAStrutsのドキュメントにもこのblogでも書いていますが、1つのEntityに閉じたロジックならEntityに記述するということでいいと思います。複数のユースケースで使うからこそ、Entityに書く意味がありますね。個別のユースケースでしか使わないなら、Actionに書いたほうがいいと思います。

上記のひがさんのエントリーを元に「どのクラスに処理を記述すべきか？」の
方針を図示して整理してみました。

というのも、「どのクラスに処理を記述すべきか？」を考えるにあたって
いくつかの判断が必要ですが、判断対象の順序次第でえらく混乱を招くことを実感したため、
判断の順番を考慮したフローチャートベースのシンプルで明確な方針（ルール）の必要性を感じたからです。
（実際に、最初に「複数のAction（ユースケース）で使われるか？」という判断から検討した結果、結構混乱しました。）

追記：
当初は『複数種類のEntityにまたがっているロジックは、制御ロジックととらえて、Logicに持たせるのが基準が明快なのでわかりやすいのではないでしょうか。』ということでした。しかし、詳細は下記のエントリーを見ていただくとして、今は『複数種類のエンティティにまたがるロジックも、エンティティに書く』と考えに至っています。そんな訳で、上記のフローチャートは一旦保留。

　複数種類のエンティティを扱うロジックをどこに書くのか
　http://d.hatena.ne.jp/higayasuo/20080208#1202449061

こういった方針をきちんと示さずにいると、
「いびつに肥大化したユーティリィティ」や
「確信犯的なコピ＆ペーストの山」に
プロジェクトのソースコードが汚染されてしまうので、
DRY原則を実践する上でも、とても大切なことだと認識しています。

また、ここで挙げた方針が適切かどうかは別として、
　「１つの方針をメンバー間で共有して深くコンセンサスを得たうえで」、
　「方針に照らし合わせて各個別の事象がどう有るべきかをメンバーと対話しながら検討する」
というプロセスが非常に大事だと思いました。
（あと、経験や先入観がルールベースの思考を妨げる要因になることも改めて実感できた。）

まあ、結論は「判断の順序重要」ということで。