レイヤー vs ドメイン比較

はじめに

イノベーショングループのゆるふわエンジニアのtagupoyoです。

筋トレにはまっています。

前回と同じく筋肉痛になっています。 腕をあげると激痛が走るtagupoyoです。

さて、アーキテクチャでは「レイヤー」と「ドメイン」、どちらの構造が優れているかという議論が長年続いています。

• 「変更のしやすさ」：1つの機能を変える時に、あちこちのフォルダを飛び回るレイヤー構造は非効率ではないか？
• 「認知負荷」のトレードオフ：どこに何があるか新規プロジェクト参加者にはどちらのアーキテクチャがわかりやすいか？

結局どう考えるのが現場にとって幸せなのか。今回は、私なりの考えをまとめていきます。

レイヤー vs ドメイン

さんざん議論されているレイヤー vsドメインのtagupoyoなりの考えを記載します。 いきなりレイヤー、ドメインと記載しても前提がずれるので最初にレイヤーとドメインの定義を実施します。

レイヤーについて

レイヤーはcontroller,service,repositoryといった各役割の層でわけるものです。 controllerになるものはcontrollerフォルダにすべて集約する形です。

.
├── cmd/
│    └── main.go
├── controller/
│    ├── user_handler.go
│    └── shop_handler.go
├── service/
│    ├── user_service.go
│    └── shop_service.go
├── repository/
│    ├── user_repository.go
│    └── shop_repository.go
└── model/ (entity)
     ├── user.go
     └── shop.go

ドメインにについて

ドメインは各ドメインによって分割される構成です。 userというフォルダに各種の構成を入力するような形です。 厳密にはドメインの中にレイヤーを構造を記載している形となります。

.
├── cmd/
│    └── main.go
├── user/
│    ├── user_handler.go
│    ├── user_service.go
│    ├── user_repository.go
│    └── user.go
└── shop/
     ├── shop_handler.go
     ├── shop_service.go
     ├── shop_repository.go
     └── shop.go

メリット・デメリット

レイヤーのメリット・デメリット

レイヤー構造のメリットはなんといってもその認知度にあります。 ※tagupoyoもエンジニアデビューをした時に実際に初めて触ったものはレイヤー構造でした。

各責務がレイヤー毎に分割されているためどこになにがあるのが理解しやすいです。

ただ、コードが成熟すると(体感2年間ぐらいです)コードが肥大化、フォルダ内での機能が様々に依存していき改修が大変になってきました。 設計の問題だろというご指摘は許してください

ドメインのメリット・デメリット

ドメインの構造はドメイン毎にファイルを配置する形になります。 機能が集約されているため、これは何を実施するのかがわかりやすいです。 単一責任の原則にもある通り、各ドメインに機能が集約されているため機能が肥大化してもほかのファイルに影響が少ないと考えています。

かつ、Vibe Codingとの親和性が高くコードの生産性アップにもつながると考えております。 レイヤーの場合はコードを確認する箇所が多いため、コンテキストが肥大化してしまい品質があまり良くないイメージがあります。 ドメインの場合は集約されているので品質はある程度担保されます。

まとめ

レイヤー・ドメインのどちらが良いかのさくっと記載しました。 個人的にはドメイン・レイヤーで比較するとドメインの方に軍配が上がります。

ただ、tagupoyoの個人的な解釈になりますが、ソフトウェアはハードウェアと違い中身の手順(コード)をすぐに変更できるため、構造は最初にこれだと決めずに変化に耐えうるような設計がいいと考えております。

変化に耐えうると言って抽象を持たせすぎるとしんどいので、抽象と具象のいい具合をみつけるのが設計の肝となると思っています。

具体的には最初からxxアーキテクチャと決定せずにフラットパッケージで実施して、ファイル数/機能に応じて変更していくのが正解だと考えます。