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

https://blog.starbug1.com/archives/2695 のミラーです。

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

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

実際のところ

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

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

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

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

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

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

ビジネスルール- ビジネスに関する方針を表現したもの（経路、位置、輸送、価格、製品など）ワークフロー- ある関係者（人間またはソフトウェア）から他の関係者へと文書やデータを渡す仕事の順序

ビジネスロジック

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

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

ビジネスロジック

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

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

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

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

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

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

技術詳細

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

機能仕様

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

ビジネスロジック

残った「業務の専門家が認識している知識」が純粋なビジネスロジックです。業務に関する判定ロジックなどの業務上の方針やルールなどが該当します。そして、これらは元々業務の専門家が認識している知識であるため、処理内容を説明すれば業務の専門家にとっても理解できる物であるはずです。この部分が純粋に保たれていれば、業務上の仕様変更があった場合にもスムーズに対応できそうです。

ソフトウェア設計に活かす

ここまでの内容で、ビジネスロジックに対する解像度が上がって、純粋なビジネスロジックとそれ以外の物との区別ができるようになりました。純粋なビジネスロジックを、アーキテクチャの工夫によって、その他の様々な詳細から隔離された状態に保つ事ができれば、安定したシステム運用が目指せると考えています。

レガシープロジェクトの改善のために、ビジネスロジックをドメインに隔離することについて過去に記事を書いているので、こちらも見てみてください。

ドメインを純粋に保つ (レガシープロジェクトの改善活動について)

ビジネスロジックに対する解像度を上げることは、書籍『クリーンアーキテクチャ』『エリックエヴァンスのドメイン駆動設計』等を参考にして自分達のシステムのアーキテクチャを決定する際にも役立つと思います。

最後まで読んでいただきありがとうございます。フィードバック等いただけると嬉しいです。

参考文献

優れたデザインにとってコンセプトが重要な理由: 使いやすく安心なソフトウェアを作るために

この本で語られるコンセプトというものは、システム外部から観察可能なものとして描かれていました。このブログエントリで扱っている純粋なビジネスロジックも、同様にシステム外部から観察可能であるという気付きがありました。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

技術詳細を外に追い出すという観点を参考にしています。