アプリケーションレイヤ
#設計 #レイヤードアーキテクチャ
WEBアプリケーションやフレームワーク固有の関心ごとで、どのアプリ作る上でも大体出てくる
ドメイン知識は持たない
routesやWeb APIの振り分けを行うController
非機能要件の知識
エラーハンドリング
大体は専用のライブラリが存在する
自分でつくろうとすると大変
素直にライブラリを利用するとよい
パフォーマンスを追求しはじめると計算機科学(CS)の深い知識やアルゴリズムが必要となってくる
ライブラリのお作法にしたがうと利用者は設計と速度が両立したロジックを書ける
ボイラープレートを減らしてくれる
RailsはWebアプリ全体を抽象化した
TanStack QueryはServer Stateを抽象化した
キャッシュ管理はアプリケーションレイヤの一種だと思うkoushisa.icon
外界の世界や基盤技術の影響を受けやすい
プラットフォーム側の制約とか
インフラ技術は3年程度で新しくなる
歴史的には3年ごとにデータアクセスのテクニックは変更される
このあたりの知識は技術トレンドの新陳代謝がはげしいので陳腐化もはやいkoushisa.icon
技術の進化により抽象度も高まる傾向にある
自身が変化する速度 < 世界が変化する速度なので車輪の再発明はやめておくに越したことはない
息の長いプロダクトではアプリレイヤのUIの改善、ユースケースの再設計などの新陳代謝にドメインが巻き込まれないように、関心事の分離をする
DDDとかオニオンアーキテクチャとかレイヤードアーキテクチャとか
ビジネスロジック: サービス(Service)
データアクセス: Repository
ドメインモデル: Entity
ドメインモデルの内部には、永続化にまつわる情報を混入させるべきではない
関連
ETC原則