レイヤーアーキテクチャ（層構造）では、役割ごとに「Presentation層」「Business Logic層」「Data層」に分割することで可読性や保守性を高められますが、過度なカプセル化（内部実装を隠蔽しすぎること）はシステムの冗長化や性能低下を招きます。
このため、あえてレイヤー間のブラックボックスを外し、最上位層から最下位層のエンティティを直接扱う設計を許可するケースがあります。
その際、DTO（Data Transfer Object）を使えばレイヤー間の分離を維持できますが、クラス数やマッピング処理が増えて実装が煩雑になりがちです。
下記にDTOや直接受け渡しについて、調べたことをまとめてみました。
1.レイヤーアーキテクチャとは
3層（Three-Tier）モデルの構造
3層アーキテクチャは、ユーザーインターフェースを担うPresentation層、業務ロジックを担うBusiness Logic層、データアクセスを担うData層に分ける設計パターンです。
Presentation層とData層は直接通信せず、必ずBusiness Logic層を経由することで依存関係を明確化し、安全性や拡張性を向上させます。
用語解説
①レイヤー（層）
機能ごとに分割したソフトウェアの階層
②カプセル化
内部実装を隠して外部に公開する操作。
過度に進むと他層とやりとりが不便に。
③ブラックボックス
詳細を隠して扱うコンポーネントのこと。
④エンティティ
永続化されたドメインオブジェクト（例：ユーザー、注文など）。
⑤DTO（Data Transfer Object）
レイヤー間でデータを受け渡すだけのオブジェクト。
メソッドを持たず、純粋なデータ構造として使う。
2.レイヤー設計の注意点
過度なカプセル化による冗長性と性能低下
各レイヤーの抽象化は処理ステップを増やし、不要なデータ変換やメソッド呼び出しを生みます。
特にリアルタイム性や高負荷が求められるシステムでは、レイヤーをまたぐたびに遅延が積み重なり、レスポンス低下を招くことがあります。
また、複数レイヤーで同じ問題を再実装すると非効率で、コード量が増え可読性も下がります。
3.ブラックボックスを外す判断
「どうしてもこの処理だけは最下位層のエンティティを直接操作したい」という要件がある場合、あえてBusiness Logic層を通さずPresentation層からData層のエンティティを引数として渡す設計を許可することがあります。
メリット
変換処理を省略でき、実装がシンプルに 。
デメリット
層間の密結合が進み、将来的なレイヤー差し替えやテスト容易性が損なわれる可能性。
4.エンティティの直接受け渡しとDTO
直接受け渡しのケース
ブラウザから受信したJSONデータをすぐにEntityオブジェクトに詰め、Data層のリポジトリへ渡す。
コード例：
OrderEntity order = deserialize(requestBody); orderService.save(order);
のように書く。
5.DTOを使うケース
DTOを定義し、受信データをDTOにマッピング ⇒ さらにEntityへ詰め替える。この2段階マッピングで層分離を維持。
①DTOの利点
バージョニングやAPI契約の明示、Presentation層とドメインモデルの変化切り離し。
②DTOの欠点
クラス数が増え、マッパー実装やテストケースが増加し、開発コストが上がる。
6.まとめ
-
３層アーキテクチャは基本的に推奨されるが、あくまで「線引き」のためのガイドライン。
-
カプセル化しすぎると逆にパフォーマンスや可読性を損なう。
-
ブラックボックスを外す判断は、パフォーマンスや実装のシンプルさと、将来の拡張性・テスト容易性のトレードオフ。
-
DTOの使いどころを見極め、必要最小限に抑えるのがコツ。