UseCase on 設計で、迷わなくなるために | 奥田智紘

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

Wed, 11 Feb 2026 11:50:00 +0900

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

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

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

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

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

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

を整理する。

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

英語の service は、

奉仕
提供
役務

といった意味を持つ。

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

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

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

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

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

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

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

Controller
↓
Service
↓
Repository (DAO)

ここでの Service クラスは、

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

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

ViewModel が肥大化する理由

Mon, 09 Feb 2026 11:35:00 +0900

ViewModel が肥大化する理由

ViewModel が肥大化する理由

Android アプリを作っていると、ある日ふと気づきます。

ViewModel、でかくなりすぎじゃない？

State の定義、Flow の合成、エラーハンドリング、変換ロジック、画面固有の分岐……。気づけば 1 ファイルに数百行。しかも「どこを直すと何が壊れるのか分からない」状態。

この記事では、なぜ ViewModel は肥大化しやすいのか、そして それを防ぐための本質的な境界の引き方 について整理します。

よくある誤解：ViewModel は「中継役」だから重くなる

よく言われる説明に、こんなものがあります。

ViewModel は UI と Domain の橋渡しだから
Flow や State を扱うから
非同期処理が集まりやすいから

どれも一理ありますが、本当の理由ではありません。

Flow があるから肥大化するのではなく、 ViewModel が 本来持つべきでない判断 を持ち始めたときに肥大化します。

ViewModel が肥大化する本当の理由

結論から言うと理由はシンプルです。

「何をするか」を ViewModel が決め始めるから

本来の ViewModel の役割は、次の 2 つです。

UI からのイベントを受け取る
UI が描画しやすい State に変換して公開する

ところが実際には、次のような責務が入り込みがちです。

Domain と UseCase の違いを整理してみる

Mon, 09 Feb 2026 11:00:00 +0900

Domain と UseCase の違いを整理してみる

Domain と UseCase の違いを整理してみる

Clean Architecture や DDD を学んでいると、ほぼ確実に次の疑問にぶつかります。

Domain と UseCase の違いがよく分からない
どこまでが Domain で、どこからが UseCase なのか曖昧
UseCase を作ろうとすると、何を書けばいいのか分からない

私自身、このあたりで何度も立ち止まりました。この記事では、実装経験を通して整理できた Domain と UseCase の違い を、自分なりの言葉でまとめてみます。

一言で言うと何が違うのか

まず、かなり大胆に要約します。

Domain →「この世界では、何が正しく、何が成り立つか」を表す
UseCase →「その正しさを、どういう手順・文脈で使うか」を表す