アーキテクチャ

レイヤー構成

バックエンドはクリーンアーキテクチャに基づく4層で構成する。依存の向きは次のとおりで、Domain 層をすべての中心に置く。

API → UseCase → Domain ← Infrastructure

Domain 層はどの層にも依存しない。Infrastructure 層は Domain 層が定義したインターフェースを実装し、依存の向きを逆転させる。こうして技術的な詳細を Domain から切り離し、ビジネスの本質を外部技術の変更から守る。

各層は担当する関心事を1つに絞る。上位層は下位層の実装ではなく抽象に依存し、層をまたいで責務が漏れないようにする。

ビジネスの本質を表現する。フレームワークや外部技術に一切依存しない。この独立性により、技術選定が変わってもビジネスルールを保てる。

アプリケーション固有の操作を担う。Domain 層のエンティティと Repository インターフェースを組み合わせ、1つの操作を完結させる。

技術的な詳細を実装する。Domain 層が定義した Repository インターフェースの具体実装を提供し、データベースや外部サービスとの接続を担う。

外部とのインターフェースを担う。クライアントのリクエストを受け取って UseCase へ委譲する。ビジネスロジックを持たず、入出力の変換に徹する。

エラー処理の責務も層ごとに分ける。エラーの表現と変換を一箇所へ集約し、上位層での分岐を単純に保つためである。

Domain 層は、ビジネスルール違反を DomainError のサブクラスで表す。ドメインごとに固有のエラークラスを作らず、汎用エラーを全ドメインで使い回し、エラーの種類を絞る。
UseCase 層は、Domain 層のエラーをキャッチせずそのまま上位へ伝播させる。エラーの判断を一箇所へ集約するためである。
Infrastructure 層は、ドメインエラーを投げない。データの不在は戻り値で表して判断を UseCase 層へ委ね、技術的な障害はそのまま上位へ伝播させる。
API 層は、エラーを個別にキャッチしない。DomainError から TRPCError への変換を middleware に一任し、変換規則を一箇所へ保つ。