書籍メモ「Persistence Best Practices for Java Applications」Chapter 4
https://learning.oreilly.com/library/view/persistence-best-practices/9781837631278/
Part 1: Persistence in Cloud Computing – Storing and Managing Data in Modern Software Architecture
Chapter 4 Design Patterns for Data Management in Cloud-Native Applications
・Design patterns applied to the Java persistence layer
・Navigating the Java mapping landscape – evaluating framework trade-offs
・Data transfer between the view and underlying layers
レイヤード・アーキテクチャ・ソフトウェア設計パターン
それぞれが特定の責任と明確に定義されたインターフェイスを所有する、明確なレイヤーでのサービス設計と構成を推奨しています。
ロバート・マーティン、ソフトウェアにおける「腐った設計」の4つの兆候を「硬直性」「脆弱性」「不動性」「粘性」と名付けた。
この4つの兆候
剛性（Rigidity）：ソフトウェアが変化する傾向
壊れやすい（Fragility）：ソフトウェアが変更されるたびにあちこちで壊れる傾向
不動（Immobility）：他のプロジェクトのソフトウェアを再利用できない
粘り強さ（Viscosity）：コードを変更する必要があるときにハックしにくくするAPI
レイヤー
クライアント
↓
データベースクライアント
↓
マッパー
↓
データベースクライアント
↓
DAO
↓
マッパー
↓
データベースクライアント
↓
リポジトリ
↓
DAO
↓
マッパー
↓
データベース
DAOパターンは、MicrosoftによってVisual Basicで普及し、後にSunの組織を通じてJavaでも普及した。
また、初期のころはCore J2EE Patternsという本にも記載されていました。
DDDが後押しするリポジトリ・パターン
DAOとリポジトリパターンの実装の主な違いは、クライアントとデータベースの距離です。
DAOが永続化レイヤーの振る舞いを公開するのに対して、リポジトリはビジネス指向の公開になる傾向があります。
アクティブレコードは、モデルでデータベース操作を使う複雑さを軽減する方法である。
レイヤーを使う動機が理解できただろう。成熟したJavaエコシステムがあり、すべてを手作業で行う必要がないのは、フレームワークのおかげだ。
非常に多くのフレームワークがあるので、APIの使いやすさ、近さ、ランタイムに基づいて分類することができる。
・ユーザビリティ：フレームワークを見るときに評価すべき項目の1つ、そのAPIの使いやすさである。
Agnostic API／Specific API
・近接性：フレームワークとデータベース・ストレージ・エンジンは、 どの程度近接しているか？
Communication／Mapping
・ランタイム：このは、主にアノテーションの使用に依存するマッピングフレームワークに影響します。
Reflection／Reflectionless
Javaマッピングフレームワークにはさまざまなものがあり、APIの使いやすさ、データベース実装の詳細への近さ、実行時の機能など、それぞれがトレードオフの関係にある。プロジェクト固有のニーズを考慮し、そのニーズに最も合うフレームワークを選択することが重要だ。
DTOパターン
システムのレイヤーやコンポーネント間のデータ転送を容易にするデザインパターンです。
プレゼンテーション層をビジネスロジックから切り離し、アプリケーションの柔軟性と保守性を高めるために使用できます。