複数テーブルを扱う際のDAO、DTO設計に悩んでいます

Question

状況

課題としてJavaEEを用いてWebアプリを制作しているのですが、
複数のテーブルからデータを取得し、一覧として表示する機能を実装するにあたり、
どのようにBO、DAO、DTOを組むのが最適か悩んでおります。

また、ファクトリの理解ができておらず、
DAOをハードコーディングしてしまっている状態です。

試したこと

1. DAOをテーブル単位、DTOはテーブル単位のものに加えてサービス単位のものを作り、BOでテーブル単位のDTOからサービス単位のDTOにデータをコピーする。
2. サービス単位のDAO、DTOを作り、SQLで複数テーブルからデータを取得する。

他不明な点

• リスト試したこと①において、サービス単位のDTOを作成する際にどのようにして作ればいいのか？（継承やファクトリ）

補足情報（FW/ツールのバージョンなど）

Eclipse (4.7.3a)
Java (9.0.4)
Tomcat (9.0)
MySQL (8.0.28)

最後に

お世話になっております。

独学での学習のため、オブジェクト指向やDAOパターンに対する知見が浅く、
問題が多々あるとは思いますが、ご指摘頂けますと幸いです。

初歩的な質問とは思いますが、ご教示頂けますよう、よろしくお願いいたします。

Answer 1

BO（ビジネスオブジェクト）とDTO（データトランスファーオブジェクト）の設計:

BO: ビジネスロジックを含むオブジェクトで、データの取得、変換、およびビジネスルールの実行を担当します。
DTO: データを格納し、異なるレイヤー間で情報を伝達するためのオブジェクトです。
BOとDTOは、アプリケーションの要件に基づいて設計されるべきです。BOは特定のビジネスルールを実装し、DTOはデータを受け渡すために使用されます。BO内でDTOからDTOへのデータコピーを実行するのは一般的なアプローチです。

DAO（データアクセスオブジェクト）の設計:

DAOはデータベースとの対話を担当します。
テーブルごとにDAOを設計するのは一般的ですが、複数テーブルからデータを取得する場合は、特定のビジネス機能に対応するDAO（サービス単位のDAO）を設計することができます。
ファクトリについて心配しないでください。ファクトリは、オブジェクトの生成を抽象化するためのデザインパターンです。最初にDAOをハードコーディングしてしまっても、将来的にファクトリパターンを導入してコードをリファクタリングできます。

サービス層の導入:

サービス層は、ビジネスロジックを集約し、DAOとの対話を調整するのに役立ちます。
サービス層で複数のテーブルからデータを取得し、BOに渡すことができます。
リスト試したこと①:

サービス単位のDTOを作成する際、継承よりもコンポジションを検討することが一般的です。サービス単位のDTOは、必要なデータフィールドを持つべきで、継承よりも柔軟性があります。
ファクトリは、新しいオブジェクトを生成するためのユーティリティです。ファクトリメソッドを使用して新しいオブジェクトを作成し、コードを洗練させることができます。
最後に、オブジェクト指向設計とデザインパターンに関する知識を深めるために、書籍やオンラインコースを利用することをお勧めします。また、実際のプロジェクトで経験を積むことも非常に役立ちます。

Answer 2

https://ts0818.hatenablog.com/entry/2021/07/25/110657
こちらのサイトで丁寧に解説してくださっていましたので、
それを参考にして進めたいと思います。