エンティティベースのServiceとRepositoryのドグマ
エンタープライズアプリケーションアーキテクチャにおいて、Service LayerやRepositoryパターンをエンティティ単位で設計することは広く浸透しているが、必ずしも最善のアプローチとは限らない。本記事では、この「エンティティベース」の設計思想がドグマ（教条）化している問題を指摘し、ユースケースやビジネス機能に基づいたより実践的な設計手法を提案する。
背景メモ
- これはソフトウェア設計パターンの古典とも言える、Martin Fowlerが自身のサイト（P of EAAカタログ）で公開しているエントリ。Service Layer（サービス層）パターンを、ドメイン層とは別個のレイヤーとして明示的に定義している。<br>- 背景として、多くの開発者が「1エンティティに1サービス＋1リポジトリ」というパターンを無批判に繰り返す慣習（いわゆる"エンティティベースのサービス"）に対して批判を投げかけている。CRUDをそのままサービスとして露出するだけでは設計価値が低く、真のService Layerはビジネスロジックの編成とトランザクションの境界として機能すべきだという主張。<br>- Fowlerのこのカタログは「エンタープライズアプリケーションアーキテクチャパターン」として広く参照されており、特にJava/.NET系のバックエンド設計におけるService LayerとRepositoryの議論では頻繁に引用される。