ビジネスロジック

コンピュータソフトウェアにおいて、ビジネスロジックまたはドメインロジックとは、データの作成、保存、変更方法を決定する現実世界のビジネスルールをコード化するプログラムの部分です。これは、データベースの管理、ユーザーインターフェースの表示、システムインフラストラクチャ、あるいはプログラムのさまざまな部分の接続といった、より低レベルの詳細に関わるソフトウェアの残りの部分とは対照的です。

ビジネスロジック：

• ビジネスオブジェクト同士の相互作用方法を規定する
• ビジネスオブジェクトへのアクセスおよび更新の経路と方法を強制します。

ビジネスルール：

• 現実世界のビジネスオブジェクト（口座、ローン、旅程、在庫など）をモデル化する

ビジネスロジックは以下で構成されます。^{[ 1 ]}

• ワークフローとは、文書やデータをある参加者（人またはソフトウェアシステム）から別の参加者（人またはソフトウェアシステム）へ渡す一連の順序付けられたタスクのことである。

ビジネスロジックはビジネスルールとは区別されるべきである。^{[ 2 ]}ビジネスロジックは、エンタープライズシステムにおいて、データの変換や計算方法、および人やソフトウェアへのルーティング方法（ワークフロー）を決定する部分である。ビジネスルールは、ビジネスポリシーの形式的な表現である。プロセスまたは手順であるものはすべてビジネスロジックであり、プロセスでも手順でもないものはビジネスルールである。新しい訪問者を歓迎することは、実行すべき手順からなるプロセス（ワークフロー）であるが、すべての新しい訪問者を歓迎しなければならないという記述はビジネスルールである。さらに、ビジネスロジックは手続き的であるのに対し、ビジネスルールは宣言的である。^{[ 3 ]}

例えば、eコマースウェブサイトでは、訪問者が商品をショッピングカートに追加したり、配送先住所を指定したり、支払い情報を入力したりできる場合があります。ウェブサイトのビジネスロジックには、次のようなワークフローが含まれる可能性があります。

• チェックアウト中に発生する一連のイベント。例えば、複数ページにわたるフォームで、最初に配送先住所、次に請求先住所、次のページに支払い方法、最後のページにお祝いのメッセージが表示されるといった流れです。

ウェブサイトには利用規約も設けられます。

• 商品説明ページから同じ商品を複数回追加すると、その商品の数量が増加します。
• 訪問者の住所、メールアドレス、クレジットカード情報は、特定の形式に従う必要があります。
• クレジットカードネットワークと通信するための特定の通信プロトコル

ウェブサイトのソフトウェアには、ビジネスロジックやビジネスルールの一部とはみなされないその他のコードも含まれています。

• サイトの色、外観、背景画像、ナビゲーション構造を定義するHTMLなど、コアビジネスデータとは関係のない周辺コンテンツ
• 汎用的なエラー処理コード（例：HTTPエラーコード500ページを表示するコード）
• ウェブサーバーがサイトを起動する際に実行される初期化コードで、システムの設定を行います。
• インフラストラクチャを監視し、サイトのすべての部分が正常に機能していることを確認する（例：課金システムが利用可能であること）。
• ネットワーク接続の確立、データベースへのオブジェクトの送信、HTTP POSTイベントによるユーザー入力の解析などを行うための汎用コード。

ビジネスロジックはプログラム内のどこにでも配置できます。例えば、住所の特定の形式が与えられた場合、ビジネスロジックで指定されたフィールドに正確に対応する列を持つデータベーステーブルを作成し、無効なデータが追加されないように型チェックを追加することができます。

ビジネスロジックは頻繁に変更されます。たとえば、オンライン小売業者が新しい国に商品を発送し始めると、許可される住所形式のセットが変わる可能性があります。そのため、ビジネスロジックを実装するコードを比較的分離、つまり疎結合にすることが望ましいとよく考えられています。これにより、ビジネスロジックの変更は、コードの1つの部分のみの小さなコードセットの変更で済む可能性が高くなります。離れているが強く結合したコードは、プログラマーが必要な変更の一部のみを行い、システムの一部を見落とし、誤った動作につながるリスクも高くなります。^{[ 4 ]}

マルチティアアーキテクチャでは、データアクセス層やサービス層など、他の層とは分離されたビジネスロジック層を作成することで、この分離を形式化します。各層は、他の層のコードについて最小限の情報しか「知りません」。必要なタスクを実行するのに十分な情報だけです。たとえば、モデル・ビュー・コントローラー（MVC）パラダイムでは、コントローラー層とビュー層をできるだけ小さくし、すべてのビジネスロジックをモデルに集中させることができます。eコマースの例では、コントローラーがチェックアウトシーケンスのWebページの順序を決定し、電子メール、住所、支払い情報がビジネスルールを満たしていることを検証する責任も負います（これらの検証をデータベース自体や下位レベルのデータベースアクセスコードに任せるのではなく）。

代替的なパラダイムも可能です。例えば、比較的単純なビジネスエンティティの場合、汎用的なビューとコントローラがデータベースオブジェクトにアクセスでき、そのデータベースオブジェクト自体が、受け入れるフォーマットや可能な変更に関するすべての関連ビジネスロジック（データベースモデルとして知られています）を含んでいます。

階層型アーキテクチャの中には、独立したアプリケーション層またはサービス層を使用するものもあれば、ビジネスロジック層をそれらのいずれかと同一視するものもあります。

ビジネスロジックは、ビジネスルール管理システム（BRMS）を使用して手続き型コードから抽出できます。^{[ 5 ]}

ソフトウェア開発におけるビジネスルールアプローチは、BRMS（ビジネスルール管理システム）を使用し、ビジネスロジックとその他のコードを厳密に分離します。ユーザーインターフェース管理システムも、ビジネスロジックとその他のコードを厳密に分離するために使用される技術です。マジックプッシュボタンは「アンチパターン」とみなされます。この場合、この手法は望ましくない制約を生み出し、保守しやすい方法でビジネスロジックをコーディングすることを困難にします。

ドメインモデルとは、ビジネスルールで必要とされるデータストレージの種類を抽象的に表現したものです。

• ドラコンチャート
• ロジックの再配置
• ビジネスプロセスモデリング
• モデル・ビュー・コントローラ

• ブレット・マクラフリン（ 2002年3月）「ビジネスロジック、パート1」『 Javaエンタープライズアプリケーションの構築、第1巻：アーキテクチャ』オライリー・アンド・アソシエイツ。ISBN 0-596-00123-1。マクラフリンは、アプリケーションのビジネス層を実装するためのファサードパターンについて論じている。
• Kathy Bohrer (1997 年 11 月) 「ミドルウェアはビジネスロジックを分離する」Object Magazine 7 ( 9) 。ニューヨーク、米国: SIGS Publications, Inc.: 41–46。ISSN 1055-3614 。 
• 久野晴美、マイク・レモン、アラン・カープ、ドロテア・ベリンガー (2001)。「会話 + インターフェース = ビジネスロジック」。F. Casati、D. Georgakopoulos、M.-C. Shan (編)『Eサービスのためのテクノロジー：第2回国際ワークショップ、TES 2001、イタリア、ローマ、2001年9月14～15日、議事録』。Lecture Notes in Computer Science、第 2193巻、Springer Berlin / Heidelberg、ISSN 0302-9743。 
• Volker Turau (2002). 「XMLに基づくWebベースデータ入力アプリケーションの自動生成フレームワーク」 . 2002年ACM応用コンピューティングシンポジウム議事録、マドリード、スペイン：Webおよびeビジネスアプリケーション. ACM Press. pp. 1121–1126 . ISBN  1-58113-445-2。Turauは、 JavaサーブレットとJavaServer Pagesを使用して実装されたアプリケーションフレームワークを紹介している。このフレームワークは、ビジネスロジックとプレゼンテーションロジックを分離し、それぞれを比較的独立しながらも連携する経路で並行して開発することを可能にする。
• Pau, L.-F. & Vervest, PHM (2003-12-08). "ネットワークベースのビジネスプロセス管理：通信ネットワークへのビジネスロジックの組み込み". ERIM レポートシリーズ 経営学研究.エラスムス大学. hdl : 1765/1070 .{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ) — Pau と Vervest は、ネットワークの観点からビジネス リソースの割り当てを最適化するために、多数のアクターを持つ分散アプリケーションの基盤となる通信ネットワークにビジネス ロジックを組み込むアプローチを開発しました。

• ビジネスレイヤーガイドライン