「レイヤードアーキテクチャって聞いたことはあるけど、正しく説明できない…」
「Service に全部書いてしまって、コードがぐちゃぐちゃになっている…」
そんな悩みを持っていませんか？
レイヤードアーキテクチャは、Javaエンジニアにとって必須レベルの設計手法です。特に業務システム開発では、ほぼ標準と言っていいほど使われています。
この記事では、
- レイヤードアーキテクチャの正しい考え方
- 各レイヤーの責務
- Javaでの具体的な設計例
- 神クラスを生まないコツ
- Javaを学ぶメリット
を、小学生でもわかるやさしい言葉で解説します。
レイヤードアーキテクチャとは？まずは全体像を理解しよう
レイヤードアーキテクチャとは、
アプリケーションを「層」に分けて整理する設計方法です。
イメージは「ケーキの層」です。
- 一番上：画面やAPIの層
- 真ん中：アプリの処理の流れを決める層
- その下：ビジネスルールの層
- 一番下：データベースなどの層
それぞれの役割をハッキリ分けることで、
- コードが読みやすくなる
- 修正しやすくなる
- チーム開発がスムーズになる
という大きなメリットがあります。
レイヤードアーキテクチャの基本構造
一般的に、次のような四つの層に分かれます。
| 層 | 役割 |
|---|---|
| プレゼンテーション層 | 画面・APIとのやり取り |
| アプリケーション層 | 処理の流れを制御 |
| ドメイン層 | ビジネスルール |
| インフラストラクチャ層 | DBや外部サービス |
とてもシンプルですよね。
しかし、正しく設計できている人は意外と少ないのが現実です。
正しい設計の大原則｜依存方向を守れ
レイヤードアーキテクチャには、絶対に守るべきルールがあります。
上の層は下の層に依存する
下の層は上の層を知らない
これが大原則です。
たとえば、
- Controller → Service を呼ぶのはOK
- Service → Controller を呼ぶのはNG
下の層が上の層を知ってしまうと、依存関係がぐちゃぐちゃになります。
これがスパゲッティコードの始まりです。
各レイヤーの正しい責務
ここからが重要です。
プレゼンテーション層
役割は「受付係」です。
- リクエストを受け取る
- 必要なデータをServiceへ渡す
- 結果を返す
ここにビジネスロジックを書いてはいけません。
悪い例
@PostMapping("/order")
public String order(@RequestParam int quantity) {
if (quantity <= 0) {
throw new IllegalArgumentException();
}
// 在庫計算ロジック
}
ビジネスルールはドメインに書くべきです。
アプリケーション層
役割は「司令塔」です。
- 処理の流れを決める
- トランザクション管理
- ドメイン同士をつなぐ
public class OrderService { private final ProductRepository repository; public void orderProduct(int productId, int quantity) {
Product product = repository.findById(productId);
product.decreaseStock(quantity);
repository.save(product);
}
}
ここで重要なのは、ロジックの詳細は書かないことです。
ドメイン層
ここが心臓部です。
ビジネスルールはすべてここに書きます。
public class Product { private int stock; public void decreaseStock(int quantity) {
if (quantity <= 0) {
throw new IllegalArgumentException("数量が不正です");
}
if (stock < quantity) {
throw new IllegalStateException("在庫不足です");
}
stock -= quantity;
}
}
このように、在庫はマイナスにならないというルールはドメインに書きます。
これが正しい設計です。
インフラストラクチャ層
ここは「外の世界との接点」です。
- データベース
- 外部API
- メール送信
public class ProductRepository { public Product findById(int id) {
// DBアクセス処理
} public void save(Product product) {
// DB保存処理
}
}
SQLはここに閉じ込めます。
Javaでレイヤードアーキテクチャが強い理由
Javaは業務システムで圧倒的に使われています。
理由は、
- 型が強い
- 大規模開発に向いている
- フレームワークが豊富
- 長年の実績がある
特にSpring系フレームワークとの相性は抜群です。
レイヤード設計を理解したJavaエンジニアは、現場で非常に評価されます。
神クラスを防ぐ方法
初心者がやりがちなのが、
Serviceに全部書く問題
これを防ぐコツは、
- ビジネスルールはドメインへ
- 処理の流れだけをServiceに
- DBアクセスはRepositoryに
役割を徹底的に分けることです。
DTOは分けるべき？
基本は分けることをおすすめします。
- Entityはビジネスルール用
- DTOは画面通信用
小さなアプリでは共通でも構いませんが、
本格的な業務システムでは分けたほうが安全です。
トランザクションはどこに書く？
基本はアプリケーション層です。
理由は、
- 処理単位で管理できる
- ドメインを汚さない
これも実務では非常に重要です。
レイヤードアーキテクチャを学ぶメリット
これを理解していると、
- 設計レビューに強くなる
- 面接で差がつく
- 大規模案件で活躍できる
Javaエンジニアとしての市場価値が上がります。
絶対にJavaプログラマーになりたい人へ
まずは基礎を固めることが重要です。
独学で始めるなら、
👉 絶対にJavaプログラマーになりたい人へ。
https://amzn.asia/d/3E1CYbv
この本で基礎を固めてください。
設計の考え方も含めて、Javaの本質が理解できます。
それでも不安な人へ
- コードレビューを受けたい
- 本気でJavaエンジニアに転職したい
- 実務レベルの設計を身につけたい
そんな人は
👉 サイゼントアカデミー
https://academy.cyzennt.co.jp
現役エンジニアからレビューを受けながら学べます。
まとめ｜レイヤーを守るだけでコードは変わる
レイヤードアーキテクチャは難しくありません。
守るべきことはシンプルです。
- 責務を分ける
- 依存方向を守る
- ビジネスルールはドメインへ
これだけで、あなたのコードは劇的に変わります。
Javaは今も第一線で使われる最強クラスの言語です。
正しい設計を身につけて、
市場価値の高いJavaエンジニアになりましょう。
コメント