Struts、Spring、Hibernateを使用する大規模なJavaアプリを継承しました。私が毎日扱っているクラスとインターフェースは、Strutsアクション、Struts ActionForms、値オブジェクト、サービスインターフェースと実装、DAOインターフェースと実装、およびエンティティです。ActionForms、Value Objects、およびEntitiesの間の責任の正しい分離について確信が持てないことを除いて、これらのほとんどの方法と理由についてはかなり明確です。また、ドメインモデル（つまり、すべてのエンティティ）には、実際のビジネスロジックが（あるとしても）あまり含まれていないことにも言及する必要があります。これは本質的にCRUDアプリであり、実際のロジックのほとんどはデータベースにあります（うん！）。とにかく、私が疑問に思っているいくつかの明確なJava関連の問題があります。
1）エンティティと値オブジェクト（VO）の間に大きな違いはないようであり、どちらかの方向にサービスレイヤーを通過するときに、他のオブジェクトに変換するために多くのコードを記述する必要があります（Strutsアクションは処理するだけです） VO、DAOはエンティティのみを扱います）。したがって、VOとエンティティはやや冗長に見えます。なぜ両方を持っているのですか？
2）VO <->エンティティ変換コードはどこに配置する必要がありますか？サービスレイヤー、エンティティ、VO？
3）VOはActionFormsに直接配置され、JSPのタグに直接バインドされます（例）。これは良い習慣ですか？そうでない場合、適切なデザインは何ですか？
4）値オブジェクトで外部キーの依存関係を適切に処理する方法が不明です。たとえば、特定のVOには、データベース用語で、タイプテーブルへの外部キー関係を表すタイプフィールドがあります。UIでは、これは、ユーザーがタイプを選択できるドロップダウンフィールド、またはタイプのテキスト表現を単に表示するラベル（画面によって異なります）に変換されます。さて、VOには、タイプID、タイプのテキスト表現、またはその両方のプロパティが必要ですか？誰がいつ、2つの間を翻訳する責任がありますか？
5）VOには、データベースIDのフィールドがあります。VOにはアイデンティティがないと思いましたか？これはどうしたの？
これらの質問が一般的な関心を引くのに十分一般的であることを願っています。これは、このタイプのアーキテクチャでは常に発生するようです。
また、このアーキテクチャはこのアプリにとって非常に重いのではないかと疑っています。より良いアーキテクチャについて提案がある場合は、先に進んでください。ただし、別のアーキテクチャは長期的なリファクタリングであり、現在は実行できないため、主に上記の質問への回答に関心があります。