ビジネスロジック

ビジネスロジック（）、あるいはドメインロジック（）、業務ロジックは、どのようにデータが作成され、保存され、変更されるかについてを表現するプログラムにおける部分であり、アプリケーション固有の処理を指す。データベースの管理やUIの表示、システムインフラ、プログラム全体における各部の接続などを表現する、プログラムにおけるより低水準な残りの部分とは対照的な概念である。

ドメインロジックという場合、あるドメインに関するビジネスロジックのことを指す場合が多い。

この用語は、主にプログラムが層構造となるアプリケーション開発で用いられる。三層アーキテクチャにおいては、ビジネスロジックは中間層に位置する。

アルゴリズムは問題が与えられた時の具体的な情報の処理手順であり、アプリケーション固有のものではない一方で、ビジネスロジックはアプリケーション固有の処理であるという点で、これらは異なる概念である。ビジネスロジックには、アプリケーションの目的を達成するための処理を定義する、一連のルール、アルゴリズム、計算処理が含まれる。

 ビジネスロジックの範囲 
 実世界のビジネスオブジェクト（勘定、貸付金、旅程表、在庫目録などなど）をモデル化したもの
 そのようなビジネスオブジェクト間の相互作用を示したもの
 ビジネスオブジェクトにアクセス・更新する経路と方法を示したもの

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

 ビジネスロジックの位置 

単層アプリケーションでは、プレゼンテーション部分とビジネスロジックとデータベース部分が融合し、相互に知識を共有し、結合度が高い。この状態では、一部の修正が他の部分に影響を与えるため、一箇所の変更のためにシステム全体を再度テストし直さなくてはならなくなる。また、データベース部やビジネスロジックの再利用性も低下する。

多層アーキテクチャでは、ビジネスロジックは分離されたモジュールとなる。一般的な3層アーキテクチャでは、ビジネスロジックは中間層を形成する（ビジネス層、ビジネスロジック層などと呼ぶ）。実際には、ストアドプロシージャや入力チェックおよび表示形式などの決定という形でビジネスロジックの一部は、他の2つの階層（ユーザサービス層とデータベースサービス層）にも織り込まれる。Hower らはこのような方式を批判し、ビジネスロジックは全てビジネス層で保持すべきで、ユーザサービス層やデータベースサービス層にビジネスロジックを含めないようにすべきだと主張している。

 脚注 

 参考文献 
  — McLaughlin はFacade パターンを使ってビジネスロジック層を実装する手法を論じている。


  — Java Servlet と JavaServer Pages を使ったアプリケーションフレームワークの解説。ビジネスロジックとプレゼンテーションの分離ができ、双方の開発がスムーズになる。


関連項目
 ソフトウェア工学
 Enterprise JavaBeans
 ユーザインタフェース管理システム(UIMS)
 Magic pushbutton - アンチパターンの一種
 ビジネスロジック層
 プレゼンテーションロジック

ひしねすろしつく
ひしねすろしつく