「この用語、毎回出てくるけど結局何が違うの？」――要件定義のたびにそんなモヤモヤを感じたことがあるなら、その感覚は正しい。「サービス」「ドメイン」「機能」は似て非なるもの。それぞれの輪郭を一度ハッキリさせれば、設計書の理解も、会話のすれ違いも、ぐっと減る。
Contents
サービス・ドメイン・機能の違いはなぜ混乱するのか
3つの言葉は使われる文脈が重なるため、混乱を招く。特に設計書や開発ドキュメントでは、明確な定義が省略されやすい。結果、チーム内で「同じ単語なのに違う意味」で会話が進む。
Martin Fowlerは「Service という言葉は、文脈によってまったく異なる意味を持つ」と述べている。これは設計の現場で生じる用語のブレを象徴する発言。Red Hatのドキュメントでも、「Service、Feature、Domainの違いを曖昧にしないことがソフトウェア品質の第一歩」と記載されている。
機能とはなにか ― ユーザーができること
機能（Feature）は、アプリやサービスを通じてユーザーが実行できる操作や動作を指す。
- 商品を検索できる
- ログインできる
- クレジットカードで決済できる
「できること」＝機能。アプリをリモコンだとすれば、ボタンが機能にあたる。押したときに何が起こるか。それが機能の定義となる。
ドメインとはなにか ― ビジネスの世界そのもの
ドメイン（Domain）は、そのアプリケーションやサービスが取り扱う「世界」の範囲を示す。ユーザーではなく、企業やビジネスの視点で切り取られた対象領域。
- 銀行なら「融資」「口座」「審査」
- 医療なら「診察」「投薬」「患者管理」
DDD（ドメイン駆動設計）では、「ドメインとは、問題を解決するための知識と活動の集合」と定義されている。
比喩で言えば、ドメインは“街の地図”。地図が示す範囲がアプリのドメインとなる。地図の中にある建物（サービス）、建物の中の設備（機能）という関係で考えると整理しやすい。
サービスとはなにか ― 機能を提供する入り口
サービス（Service）は、ある機能を外部に提供する役割を持つ「窓口」。
- ログインサービス
- 支払いサービス
- 在庫確認サービス
機能そのものではない。機能を「使えるようにする」ための装置。
例えば、自動販売機を思い浮かべる。飲み物を冷やすのが機能、飲み物を売るのがサービス。中にある仕組み（冷却、補充、排出）は隠されているが、サービスとしてはボタンとお金の投入口だけが見えている。
APIやマイクロサービスは、サービスを「機能化」した具体例。外部からリクエストを受けて、内部で処理を実行し、結果を返すという流れを取る。
GoogleやNetflixのサービス設計
Google Cloudのマイクロサービス設計ガイドでは、「ビジネスドメインごとにサービスを分離することが理想」とされている。つまり、1サービス＝1ドメインの一部。
Netflixは、ユーザー体験の最適化のために、数百のマイクロサービスを使い分けている。視聴履歴の管理、レコメンデーション、再生制御、それぞれに専用サービスが存在する。
これらの事例に共通するのは「ドメインに対応するサービスがあり、そのサービスが機能を外に見せる」という構造。
よくある誤解とその整理
- 機能をドメインと誤解
→ 「ログイン機能」がドメインであることはない。「認証・認可」というドメインの一部に含まれる機能 - サービスを機能の集合と誤解
→ サービスは機能を提供する「窓口」。複数の機能が1サービスでまとめられることもあるが、それは目的次第 - ドメイン＝サービスと誤解
→ ドメインは「何のために存在するか」、サービスは「どうやって提供するか」
チェックリスト：
- 誰の視点か？（ユーザー／開発者／ビジネス）
- どこまでの範囲を含むか？
- 再利用されるか？単発か？
- 呼ばれる側か、呼び出す側か？
まとめ
「機能」はユーザーのための動作。「ドメイン」は業務知識の範囲。「サービス」はそれらを提供する仕組み。それぞれは独立した概念でありながら、設計の現場では密接に関わっている。
違いを理解すれば、開発フェーズでの要件整理がスムーズになる。誤解のない設計は、実装と運用のコストを大きく下げる。混乱していた言葉が整理されることで、チーム間のコミュニケーションも格段に精度を増す。設計に強くなる第一歩は、言葉を正確に使うことにある。