• 「サービスクラス」とは何か？
  • 「サービス」という言葉の語源と基本ニュアンス
  • Web / サーバーサイドでの Service クラスの起源
  • なぜ「サービスクラス」が問題視されるようになったのか
  • DDD における「Service」との分岐
  • UseCase は何に対するアンチテーゼなのか
  • Web エンジニアが「サービスクラス」と言うときの意味
    • 1. 中立的な意味
    • 2. 否定的な意味（設計議論）
  • まとめ

「サービスクラス」とは何か？

──語源・ニュアンス・UseCaseとの違いを整理する

設計の議論をしていると、「それ、サービスクラスじゃない？」という言葉が出てくることがある。 一方で、Web エンジニアの中には「Service クラス」は普通に使う用語だ、という人も多い。

この「サービスクラス」という言葉は、厳密な定義がなく、文脈によって意味が変わるため、混乱を生みやすい。 この記事では、語源と歴史をたどりながら、

• なぜ「サービス」と呼ばれるのか
• Web ではどのように使われてきたのか
• なぜ設計議論では否定的に使われることがあるのか
• UseCase と何が違うのか

を整理する。

「サービス」という言葉の語源と基本ニュアンス

英語の service は、

• 奉仕
• 提供
• 役務

といった意味を持つ。

ソフトウェア設計においては、そこから転じて、

「他のオブジェクトのために処理を提供するもの」

という、かなり広い意味で使われるようになった。

この時点では、「サービス」はあくまで 役割を説明するための便利な言葉であり、設計上の厳密な概念ではない。

Web / サーバーサイドでの Service クラスの起源

「サービスクラス」という言葉が広く使われるようになったのは、 Java EE や Spring に代表される レイヤードアーキテクチャの文脈である。

典型的な構成は以下のようなものだ。

Controller
  ↓
Service
  ↓
Repository (DAO)

ここでの Service クラスは、

• Controller から呼ばれる
• 複数の Repository を組み合わせる
• トランザクション境界になる
• 業務ロジックを書く場所

という役割を担っていた。

この文脈では、Service クラスは 中立的、あるいは肯定的な存在である。

なぜ「サービスクラス」が問題視されるようになったのか

問題は、「Service」という言葉の 意味が広すぎることにある。

Service という名前は、

• 何でも入れられる
• 責務が曖昧でも違和感が出にくい
• 「とりあえずここに置く」が起きやすい

という性質を持つ。

その結果、次のようなクラスが生まれやすい。

UserService {
    login()
    logout()
    changePassword()
    resetPassword()
    sendMail()
    updateProfile()
}

これは、

• 複数の理由で変更される
• テストが肥大化する
• クラス名が振る舞いを説明していない

という問題を抱える。

こうして、

「目的が曖昧で、何でも入っているクラス」

を皮肉る意味で、 **「サービスクラス（アンチパターン）」**という言い方が使われるようになった。

DDD における「Service」との分岐

さらに混乱を招く要因として、DDD（ドメイン駆動設計）がある。

DDD には Domain Service という正当な概念が存在する。

• Entity や ValueObject に属さない
• しかしドメインとして意味のある操作

例えば：

MoneyTransferService

これはアンチパターンではない。

一方で、設計議論で問題にされる「サービスクラス」は、

• Domain Service でもない
• UseCase でもない
• ただの「便利な中間層」

という点で、まったく別物である。

UseCase は何に対するアンチテーゼなのか

UseCase は、

• Service という 広すぎる箱を否定し
• 「ユーザーの目的・操作」単位で責務を切り出す

という考え方である。

OrderService ❌

PlaceOrderUseCase ✅
CancelOrderUseCase ✅

ここで重要なのは、

• クラス名が「やること」を明確に表している
• public API が原則 1 つ
• 変更理由が 1 つに収まりやすい

という点だ。

UseCase は、「Service を使うかどうか」の問題ではなく、 責務をどう切るかに対する答えである。

Web エンジニアが「サービスクラス」と言うときの意味

Web エンジニアが「サービスクラス」という言葉を使う場合、文脈は大きく二つに分かれる。

1. 中立的な意味

• Controller にロジックを書くな
• Repository でもない処理を書く場所

という意味での「Service」。

この場合、単なるレイヤ名であり、否定的な意味はない。

2. 否定的な意味（設計議論）

• 責務が曖昧
• 何でも屋になっている
• UseCase として分解できていない

という状態を指して、

「それ、サービスクラス化していないか？」

という警告として使われる。

まとめ

• 「サービスクラス」には厳密な定義はない
• 語源的には「処理を提供するもの」という広い意味
• Web の文脈では、Controller と Repository の間の中間層として使われてきた
• その曖昧さゆえに、設計が崩れた結果の「なんでも屋」を指す言葉にもなった
• UseCase は、その曖昧さへのアンチテーゼとして生まれた考え方

重要なのは名前ではなく、 そのクラスが「何のために存在するのか」が一言で説明できるかどうかである。