はじめに
知見の薄いデザインパターンの一部についてつらつらと調べた結果を記載していく。
サーバサイド寄りのデザインパターンかも？
DTO（Data Transfer Object）
データを転送するためのオブジェクトで、主にシステム間や層間でのデータのやり取りに使用されます。ビジネスロジックを含まず、データの格納と読み出しのみを行います.
また、単純なゲッター/セッターを持つクラスです.
DAO（Data Access Object）
データベースアクセスを抽象化するオブジェクトで、データベース操作（CRUD操作など）を行うメソッドを提供します.
また、データベース操作用のメソッドを持つクラスです
※DTOとDAOを混同しやすい気がする（私だけか？）が、間違えないように。
Bean
Beanは、Javaプログラミングの基本的な構成要素として、様々なフレームワークやアプリケーションで広く使用されています。適切に設計されたBeanは、コードの再利用性、保守性、そして全体的なアプリケーションの品質を向上させる重要な役割を果たします。
まずBeanの特徴は以下。
- カプセル化: Beanは、データ（プロパティ）と振る舞い（メソッド）を1つのオブジェクトにまとめます。
- 標準化された命名規則: Beanは、getterとsetterメソッドを使用してプロパティにアクセスします。例えば、getName()やsetName(String name)のようなメソッドを持ちます。
- シリアライズ可能: Beanはオブジェクトの状態を保存したり転送したりできるように、シリアライズ可能である必要があります。
- 無引数コンストラクタ: Beanは、引数なしのpublicコンストラクタを持つ必要があります。
次にBeanの種類は以下（私の知りたい種類を記載してみた、全然全部じゃない）
- JavaBeans: 一般的なJavaアプリケーションで使用される再利用可能なコンポーネントです。
- Enterprise JavaBeans (EJB): サーバーサイドのコンポーネントモデルで、以下のタイプがあります：
Session Bean: セッション単位の処理を行う機能を持ちます5。
Entity Bean: 永続的なデータの保存や参照などに用いられます5。 - Bean Validationは、Javaオブジェクトのデータを検証するためのモデルです：
アノテーションベース: カスタムアノテーションを使用してデータの整合性を保ちます。
JSR 349準拠:
エンティティ（Entity）とは？
データのかたまりで、データとして管理したい対象がエンティティと呼べる。
いわゆるデータクラスと呼ぶやつですな
Repositoryパターン
Repositoryパターンの主な特徴は以下の通りです：
- データアクセスの抽象化: Repositoryは、データベースや永続ストレージとのやり取りを抽象化します。
- ビジネスロジックとの分離: Repositoryは、ビジネスロジックを含まず、純粋にデータの取得、保存、更新、削除などの操作に特化します。
- インターフェースの提供: Repositoryは通常、データ操作のためのインターフェースを提供し、具体的な実装はこのインターフェースを実装するクラスで行います
Repositoryは1つのエンティティ（例：User）に対して作成するのが一般的です。
機能やロールでRepositoryを分けるのは避けましょう
RepositoryパターンとDAOパターンの違い
似通っているのだが、、調べた限りではいかな違いがありそう。
（ここ100%噛み砕けていないかも。。）
主な違い
- 焦点の違い
Repository: ドメインモデル（ビジネスロジック）中心
DAO: データベーステーブル中心 - 抽象化のレベル
Repository: より高レベルな抽象化を提供
DAO: データベース操作に特化 - 使用目的
Repository: ドメインオブジェクトの永続化管理
DAO: CRUD操作の簡潔な実装 - 具体的な違い
Repositoryは「集約」という単位でデータを扱い、ビジネスロジック層がデータモデルに依存しにくくなります
（つまり、1 つの Repository に対応する DB のテーブル数は状況次第ってことになりそう）
DAOはテーブルと1対1で対応し、呼び出し側がデータモデルを意識する必要があります
終わりに
定期的にデザインパターンの勉強のし直しはしているのだが、、
プロジェクトで採用されているデザインパターンについては最低限理解できるようにしておきたい。
以上