Skip to main contentSkip to footer
Search
LINEヤフー Tech Blog

LINEヤフー株式会社のサービスを支える、技術・開発文化を発信しています。

ビジネスロジックとは何か（Wikipedia／Clean Architecture／DDD の比較と、LINE アプリ開発現場での定義）

LINE アプリのアーキテクチャの統一を推進するプロジェクトをリードしている Hiraki と申します。

アーキテクチャの議論をするうえで、ビジネスロジックという言葉はカジュアルに使われますが、人によってその意味が全く違い、議論がかみ合わない場面が多くありました。

この記事ではそんなビジネスロジックについて、LINE アプリ開発チーム内で合意できる定義を作成したので紹介します。

曖昧なビジネスロジックという言葉

ビジネスロジックという言葉は、設計や実装においてよく使われていると思います。
しかし、ビジネスロジックという言葉自体は曖昧であり、明確に定義しない限り指している概念が人によって全く異なってしまいます。

Wikipedia の定義を参照してみましょう。
私がビジネスロジックという言葉の定義を模索し始めた、2024年時点での最新の Wikipedia（日本語版）の定義（2024/07/13 Ver.）は以下のようになっていました。

ビジネスロジック（英：business logic）は、データベース上のデータに対する処理手順といったようなものを指す、ソフトウェア工学的な用語である。

一方、Wikipedia 英語版（2025/09/14 Ver.）では、以下とあります。

In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

Wikipedia 日本語版では、"データベース上の処理手段のようなもの" と定義されており、英語版では "データベースといった低レベルの詳細とは区別されるべき概念である" と異なる定義になっていました（※2024年7月時点での話であり、執筆時の最新定義（2025/01/07 Ver.）では Wikipedia 日本語版が英語版に近い定義に修正されているようです）。

LINE アプリのアーキテクチャの議論においても、このような意味の取り違いは多々ありました。
例えば、「ViewModel にはビジネスロジックが含まれるべきか否か」という議論が発生した際に、ビジネスロジックが単に DB やネットワークアクセス等の具体的なデータアクセス手段を指しているのか、UI 以外に関するデータ取得・更新等の処理全般を指しているのか、あるいは Wikipedia 英語版の定義のように具体的なデータアクセス手段とは切り離された要件の抽象的な表現なのかが噛み合わずにアーキテクチャに関する合意に時間がかかっていました。

このような認識の相違を防ぎ、円滑にアーキテクチャの議論を進行するためには、ビジネスロジックという言葉を LINE アプリ開発チーム内で明確に定義する必要があると考えました。

主要なビジネスロジックの定義の比較

言葉を独自に定義する場合は、世間一般の常識からかけ離れていない必要があります。
なぜなら、世間一般の常識からかけ離れている概念は共感が得られにくく、定着しないからです。

そこで、意味を調べる際に最初に参照するであろう Wikipedia、設計のベストプラクティスとして広く知られている The Clean Architecture 及び Domain-Driven Design におけるビジネスロジックの定義をまず理解することから始めてみます。

Wikipedia（英語版）におけるビジネスロジック

Wikipedia（英語版）におけるビジネスロジックの定義自体は先に触れた通り、以下とあります。

In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.

すなわち、ビジネスロジックとは、データの作成/補完/変更ルール等を規定するための純粋なビジネスルールをさしており、 データベースなどの低レベルな詳細とは区別されるべき概念である といえます。

主要な概念

Wikipedia（英語版）におけるビジネスロジックを取り巻く主要な概念は以下の通りです。

  • ビジネスルール：ビジネスポリシーのうち、プロセスでも手順ではない、宣言的に定義できるもの
  • ビジネスロジック：ビジネスポリシーを正式に表現したものであり、プロセスまたは手順であるもの。ビジネスルールとは区別されるべき。

ビジネスルールはビジネスロジックを指すものであると定義しているにも関わらず、概念の説明ではビジネスロジックとビジネスルールは別物と記述されていて矛盾があります。
そのため、この概念を説明している参考文献の定義も同時に見ていきたいと思います。

Wikipedia（英語版）の参考文献におけるビジネスロジック

ここで参照しているのは、"How Business Rules Relate to Business Processes from a Business Person's Point of View" になります。

この文献では、ビジネスロジックという言葉は明確には定義されていないのですが、以下の記述より、後述するビジネスプロセスとビジネスルールという概念の組み合わせと受け取ることができます。

Business rules and business processes provide different options for defining the detail of business logic

主要な概念

  • ビジネスルール：組織が目標を達成するために適用される操作、定義、制約を記述するもの（宣言的）
    • 例："顧客の負債は、与信限度額を超えてはならない"という制約
  • ビジネスプロセス：組織が目標を達成するための一連の流れを表すもの（手続き的）
    • 例：注文 → 商品を購入可能かどうかの判断 → 注文を処理または却下の一連の流れ

The Clean Architecture

The Clean Architecture のビジネスロジックの定義として参考にしたのは書籍："Clean Architecture: A Craftsman's Guide to Software Structure and Design（Robert C. Martin著）" です。

The Clean Architecture においては明確にビジネスロジックという言葉は定義されていませんが、後述する主要な概念である、"最重要ビジネスルール"と"アプリケーション固有のビジネスルール"の組み合わせと受け取ることができます。

主要な概念

  • 最重要ビジネスルール（Critical business rules）：お金を生み出したり、節約したりするルールや手続きのこと
    • 例：顧客が銀行ローンを組むための与信スコアを計算するためのルール
  • アプリケーション固有のビジネスルール（Application-specific business rules）：最重要ビジネスルール をいつ、どのように呼び出すかを規定するためのルール
    • 例：顧客が新規にローンを組めるかを検証するための、本人情報の確認 → 与信スコアの参照といった一連の流れ

Domain-Driven Design

Domain-Driven Design のビジネスロジックの定義として参考にしたのは書籍："Implementing Domain-Driven Design（Vaughn Vernon著）" です。

Domain-Driven Design においても、明確にビジネスロジックという言葉の定義はされていません。
しかし、後述する主要な概念のひとつである、ドメインモデルに含まれているもの、とされています。

主要な概念

  • ドメインモデル：ドメイン（知識領域）におけるルールの抽象的表現
  • アプリケーションサービス：ドメインモデルをいつ、どのように使うかを規定するための一連の流れを決定するもの

主要なビジネスロジックの定義の共通点と相違点

ここまでで、主要なビジネスロジックの定義を確認しました。
これらを同時に見ていくと、共通点と相違点がはっきりとします。

共通点としては、呼び名は違えど、主要な概念として以下2つが存在することです。

  • 概念1：組織が目標を達成するためルール・制約を規定するためのもの（宣言的）
  • 概念2：ルールを組み合わせて、組織が目標を達成するための一連の流れを規定するもの（手続き的）

また、上記概念1、概念2のいずれもネットワークやデータベースといった具体的なデータアクセス手段は含まれていません。

一方相違点としては、ビジネスロジックの定義となります。
具体的には共通点における2つの概念のうち、両方を含むか、いずれかを含むかが異なります。

以下表に、各参考文献におけるビジネスロジック周辺の概念とビジネスロジックとの関係を一覧できるようにまとめました。

参考文献概念1：ルール・制約を規定する概念（宣言的）概念2：一連の流れを規定する概念（手続き的）ビジネスロジックの定義
Wikipedia（英語版）ビジネスルールビジネスロジック概念2（ただし、概念1 + 概念2 とも受け取れるような記述あり）
Wikipedia（英語版）の参考文献ビジネスルールビジネスプロセス概念1 + 概念2
The Clean Architecture最重要ビジネスルールアプリケーション固有のビジネスルール概念1 + 概念2
Domain-Driven Designドメインモデルアプリケーションサービス概念1

LINE アプリ開発チーム内でのビジネスロジックの定義

LINE アプリ開発チーム内では、先に挙げた文献を参考にし、以下のように定義しています。

ビジネスロジックとは、ビジネス要件を実現するために必要な制約及び手続きであり、ネットワークアクセスやデータベースといった低レベルな詳細は含まない

主要な概念としては、The Clean Architecture と同様な言葉を使い、次のように定義しています。

  • 概念1：最重要ビジネスルール。ビジネス要件を実現するために必要な制約。プログラム上では主にモデルとして表現される。
    • 例：顧客が銀行ローンを組むための与信スコアを計算するためのルール
  • 概念2：アプリケーション固有のビジネスルール。最重要ビジネスルールを組み合わせて、ビジネス要件を達成するための一連の流れを規定するもの。プログラム上では主にユースケースとして表現される。
    • 例：顧客が新規にローンを組めるかを検証するための、本人情報の確認 → 与信スコアの参照といった一連の流れ

上記の概念1と概念2の組み合わせをビジネスロジックとし、「顧客のデータを取得するためのデータベースアクセス」等といった具体的な詳細は含まないものとしています。

このように、ビジネスロジックという言葉とそれを取り巻く概念を明確に定義したことにより、分割すべき（あるいは敢えて分割しなくてもよい）責務についての理解が深まり、LINE アプリ開発チーム内でのアーキテクチャの議論が円滑に進むようになりました。

具体的には、冒頭の「ViewModel にはビジネスロジックが含まれるべきか否か」という議論においては、 ViewModel は UI についての状態を決定する責務を提供するものであり、具体的なデータアクセス手段の提供及び前述した概念1と概念2に対応するビジネスルールの提供は責務の範囲外であることの合意ができました。

おわりに

この記事では、複数の文献におけるビジネスロジックの定義を比較しました。
共通する概念はある一方で、指す範囲や意味合いは文献ごとに異なり、明確な定義がないままでは曖昧であることを実感いただけたと思います。

LINE アプリ開発チームでは、この用語の定義を明確化したことで、アーキテクチャに関する議論を円滑に進められるようになりました。
あわせて、ビジネスロジックを取り巻く概念の理解を深めたことで、分割すべき責務の解像度も高まりました。

この記事がビジネスロジックという言葉にもやもやしている皆さんの理解の一助となれば幸いです。

参考文献