ビジネスロジックとは何か？

業務システムの設計/開発/運用の文脈での、ビジネスロジックについて考察してみたいと思います。

ソフトウェア設計についての本やブログ記事などで、「ビジネスロジックは重要である」ということは、何度も何度も言われていて常識になっていて否定する人はほとんど居ないと思います。この点については文字通りの意味で納得するところなのですが、「ビジネスロジック」というのは、何なのでしょうか？

実際のところ

ビジネスロジックとは何か？と問われて思いうかべる事は人によって異なるかもしれません。

要件定義書に書かれていることがビジネスロジック？
基本設計書に書かれていることがビジネスロジック？
○○テーブルの××カラムと□□テーブルの△△カラムを同一トランザクションで更新することがビジネスロジック？
あるページの○○ボタンをクリックしたら、行を削除するということがビジネスロジック？

どうも捉え所が無い感じです。

Wikipediaで見るビジネスロジック

ビジネスロジックの定義を求めて、Wikipediaを当たってみました。

ビジネスロジックは以下の部分からなる^:

ビジネスルール- ビジネスに関する方針を表現したもの（経路、位置、輸送、価格、製品など）

ワークフロー- ある関係者（人間またはソフトウェア）から他の関係者へと文書やデータを渡す仕事の順序

ビジネスロジック

ビジネスルールとワークフローがビジネスロジックであると書かれていました。また、同じページにビジネスロジックがいろいろな層に混ざる事を懸念する記述があります。

Hower らはこのような方式を批判し、ビジネスロジックは全てビジネス層で保持すべきで、ユーザサービス層やデータベースサービス層にビジネスロジックを含めないようにすべきだと主張しているビジネスロジック

Wikipediaに書かれていたビジネスロジックの定義「ビジネスルールとワークフロー」も、いまいちしっくり来ません。ストンと納得した感じにはなりません。そこで、思い切ってこの記事での独自の再定義をしてみます。

ビジネスロジックとは、業務の専門家が認識している知識である

我々は、業務システムを作っているプログラマーであり、コンピュータシステムの専門家という立場です。業務の専門家から依頼されて、業務の専門家達(複数かもしれない)を助ける業務システムを作っています。

業務システムを作るために業務の専門家達から得た業務に関する情報が、ビジネスロジックの元となると考えられます。もちろん、業務の専門家達から得た情報は欠けていたり整合性がなかったりすることも多いので、プログラマーがヒアリングを繰り返し再構築しなおす必要があることが多いです。こうして、プログラマーが再構築した業務の専門家が認識している知識こそが、ビジネスロジックであると定義します。

ビジネスロジックの純粋さ

Wikipediaのページにも「ビジネスロジックがいろいろな層に混ざる事を懸念」する記述がありました。ビジネスロジックは純粋なまま、その他の要素と混ざらないことが望ましいということです。ビジネスロジックを純粋に保つためには、ビジネスロジックではないものを認識して区別する必要があります。ビジネスロジックではないものも含めてリストアップしながらビジネスロジックの解像度を上げていきます。

技術詳細

データベース、テーブル、カラム、コントローラー、モデル、ビュー、JSON、ファイル、API、これらに関する処理は全てコンピュータシステムの専門家が扱うものであり、ビジネスロジックではありません。

機能仕様

また、「一覧ページに最大20件表示する」などのページの仕様も純粋なビジネスロジックとは言えません。これらは、システムを使えるようにするための機能についての仕様です。所詮コンピュータシステムの専門家が決定するものであり、「業務の専門家が認識している知識」ではないのでビジネスロジックではありません。