「クリーンアーキテクチャって理論は分かるけど、Javaでどう書くの？」
「同心円の図は見たことあるけど、パッケージ構成がイメージできない…」

そんな悩みを持つJavaエンジニアはとても多いです。

この記事では、

クリーンアーキテクチャの本質
レイヤードアーキテクチャとの違い
Javaでの具体的な実装例
Spring Bootを想定した構成
実務での落としどころ
キャリアアップにつながる理由

を、小学生でもわかるやさしい言葉で、しかし現場レベルで通用する深さで解説します。

クリーンアーキテクチャとは何か？

クリーンアーキテクチャとは、

ビジネスロジックを技術的な詳細から守る設計思想

です。

ポイントはたった一つ。

依存は必ず内側に向かう
商品を登録するAPI
商品を取得するAPI
ユースケースインターフェース
入力モデル
実装クラス
1. ユースケースはインターフェースに依存する
ドメインにJPAアノテーションを書く
ControllerがRepositoryを直接呼ぶ
何でもServiceにまとめる

依存は必ず内側に向かう

同心円の中心にあるのが「ビジネスルール」。
外側にあるのが「フレームワーク」「DB」「UI」です。

つまり、

ビジネスはSpringを知らない
ビジネスはDBを知らない
ビジネスはWebを知らない

これが最大の特徴です。

レイヤードアーキテクチャとの違い

レイヤードは「層に分ける」設計。

クリーンアーキテクチャは、

層に分ける
依存方向を厳密に制御する

という進化版です。

Javaの大規模案件では、
この設計を理解しているかどうかで評価が大きく変わります。

今回作るサンプルAPI

シンプルな例で解説します。

商品を登録するAPI

商品を取得するAPI

この二つだけに絞ります。

全体構成イメージ

com.example.product
├── domain
├── usecase
├── adapter
└── infrastructure

それぞれの役割を説明します。

ドメイン層（Entity）

ここが心臓部です。

package domain;public class Product {    private final String id;
    private String name;
    private int price;    public Product(String id, String name, int price) {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("商品名は必須です");
        }
        if (price < 0) {
            throw new IllegalArgumentException("価格は0以上です");
        }
        this.id = id;
        this.name = name;
        this.price = price;
    }    public void changePrice(int newPrice) {
        if (newPrice < 0) {
            throw new IllegalArgumentException("価格は0以上です");
        }
        this.price = newPrice;
    }    public String getId() {
        return id;
    }
}

重要なのは、

Springアノテーションなし
JPAアノテーションなし
純粋なJavaクラス

これが「汚れていないドメイン」です。

ユースケース層

ここは「処理の流れ」を定義します。

ユースケースインターフェース

package usecase;public interface RegisterProductUseCase {
    void execute(RegisterProductInput input);
}

入力モデル

package usecase;public class RegisterProductInput {
    public final String id;
    public final String name;
    public final int price;    public RegisterProductInput(String id, String name, int price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }
}

実装クラス

package usecase;import domain.Product;public class RegisterProductInteractor implements RegisterProductUseCase {    private final ProductRepository repository;    public RegisterProductInteractor(ProductRepository repository) {
        this.repository = repository;
    }    @Override
    public void execute(RegisterProductInput input) {
        Product product = new Product(input.id, input.name, input.price);
        repository.save(product);
    }
}

ここで重要なのは、

ユースケースはインターフェースに依存する

DBの詳細は知らないのです。

Repositoryインターフェース（内側）

package usecase;import domain.Product;public interface ProductRepository {
    void save(Product product);
    Product findById(String id);
}

これが依存逆転のポイントです。

インフラ層（外側）

ここで初めてSpringやJPAが登場します。

package infrastructure;import usecase.ProductRepository;
import domain.Product;public class JpaProductRepository implements ProductRepository {    @Override
    public void save(Product product) {
        // JPA保存処理
    }    @Override
    public Product findById(String id) {
        // JPA取得処理
        return null;
    }
}

ドメインはこれを知りません。

Controller（アダプタ層）

package adapter;@RestController
public class ProductController {    private final RegisterProductUseCase useCase;    public ProductController(RegisterProductUseCase useCase) {
        this.useCase = useCase;
    }    @PostMapping("/products")
    public void register(@RequestBody ProductRequest request) {
        RegisterProductInput input =
            new RegisterProductInput(request.id, request.name, request.price);
        useCase.execute(input);
    }
}

Controllerはユースケースを呼ぶだけ。

ロジックは書きません。

依存関係まとめ

層	依存してよい先
domain	なし
usecase	domain
adapter	usecase
infrastructure	usecase

外側が内側に依存します。

逆は絶対にNG。

テストが圧倒的に書きやすい

ユースケースはこうテストできます。

@Test
void 商品登録テスト() {
    ProductRepository fakeRepo = new InMemoryProductRepository();
    RegisterProductUseCase useCase =
        new RegisterProductInteractor(fakeRepo);    useCase.execute(new RegisterProductInput("1", "ペン", 100));
}

Spring不要。

DB不要。

これがJavaでクリーンアーキテクチャを採用する最大のメリットです。

よくある失敗パターン

ドメインにJPAアノテーションを書く

→ ビジネスがDBに依存してしまう

ControllerがRepositoryを直接呼ぶ

→ ユースケースが消える

何でもServiceにまとめる

→ 神クラス誕生

これらは本当に多いです。

小規模プロジェクトでの現実的な使い方

すべてを厳密に分ける必要はありません。

まずは、

ドメインを汚さない
ユースケースを作る
依存方向を守る

これだけでも十分です。

なぜJavaと相性が良いのか？

Javaは

型安全
インターフェース中心設計
テストエコシステムが豊富
長期運用案件が多い

という特徴があります。

クリーンアーキテクチャは、

「長く使うシステム」にこそ真価を発揮します。

だからJavaと相性が抜群なのです。

Javaエンジニアとして市場価値を上げる方法

クリーンアーキテクチャを理解していると、

設計レビューに強くなる
上流工程に関われる
年収アップにつながる

本気でJavaエンジニアを目指すなら、設計力は必須です。

独学するならまずこれ

👉 絶対にJavaプログラマーになりたい人へ。
https://amzn.asia/d/3E1CYbv

まずはここでJavaの基礎と設計の考え方を固めましょう。

本気で設計力を伸ばしたい人へ

コードレビューを受けたい
クリーンアーキテクチャを実践で学びたい
Javaエンジニアに転職したい

そんな方は、

👉 サイゼントアカデミー
https://academy.cyzennt.co.jp

実務レベルでの設計力が身につきます。

まとめ

クリーンアーキテクチャは難しそうに見えますが、

守るべきことはシンプルです。

ビジネスを中心に置く
依存方向を守る
技術詳細を外側に追いやる

Javaは今も最強クラスの業務言語です。

正しい設計を学び、
市場価値の高いJavaエンジニアになりましょう。

クリーンアーキテクチャをJavaで実装する実践例｜現場で通用する設計力を身につける完全ガイド