1. はじめに
ビジネスロジックは分けてください。
ビジネス・ドメインロジックは他のレイヤに依存してはいけません。
システム開発に携わると、”ビジネスロジック”や”ドメインロジック”という言葉に頻繁に聞くと思います。しかし、これらの言葉の意味や違いについて、明確な理解を持っている人は意外と少ないのではないでしょうか。この記事では、ビジネスロジックとドメインロジックについて、その違いと具体的な例を交えて解説します。
2. ビジネスロジックとドメインロジックの基本的な違い
ほとんどの場合はドメインロジック、ビジネスロジックという言葉は同じ意味として使って問題ないことが多いです。「ドメイン」という言葉と「ビジネス」という言葉は違う意味ですが、なぜロジックを付けると同じ意味になるんでしょうか。IT業界でドメイン、ビジネスという言葉は、「解決したい現実世界の問題」を指しているからです。
2.1. ビジネスロジックとは？
ビジネスロジックは、企業がビジネスを遂行する際のルールや条件、プロセスをコードで表現したものです。例えば、オンラインショップの場合、カートに商品を追加する、割引クーポンを適用する、在庫を確認するなどの処理がビジネスロジックに該当します。
2.2. ドメインロジックとは？
一方で、ドメインロジックは、ビジネスロジックの一部でもありますが、特定の「ドメイン」または業界特有の知識やルールをコードで表現したものを指します。例えば、金融業界であれば、利息計算のロジックや信用スコアの算出方法などがこれに該当します。TikTokやインスタのようなSNSアプリなら動画の撮影、鑑賞、他人への共有とフィードバックがドメインです。その一方で技術的な問題にあたるものは「ドメイン」とは区別されます。
2.3. 両者の関連性と違い
ビジネスロジックが広範なビジネスのルールやプロセスを扱うのに対し、ドメインロジックはその中でも特に業界特有の知識やルールに焦点を当てています。簡単に言えば、すべてのドメインロジックはビジネスロジックであるが、すべてのビジネスロジックがドメインロジックであるわけではありません。
2.4. 使用例で見る違い
オンラインショップ
- ビジネスロジック：カートに商品を追加、割引クーポンの適用、在庫の確認
- ドメインロジック：特定のブランドやカテゴリーに基づく推薦ロジック
金融アプリ
- ビジネスロジック：口座間の送金、残高確認
- ドメインロジック：利息の計算、信用スコアの算出
3. システムはすべて現実の問題を解決する？
3.1. システムの本質的な目的
多くの人が「システム＝問題解決」という方程式で考えがちですが、それは一面的な見方です。確かに、システムは基本的には「現実世界の問題を解決するために存在する」と言えます。しかし、その背後には多くの要素が絡み合っています。
3.2. 限定されたリソース
システムが解決すべき「問題」は、必ずしもユーザーが直面する問題だけではありません。リソース（時間、人手、予算など）が限られている中で、どの問題を優先的に解決するかも、システム設計における重要な判断の一つです。
3.3. 技術的な制約
システムが全ての問題を解決できるわけではありません。技術的な制約や、その他の外部要因によって、解決できない問題や部分的にしか解決できない問題も存在します。
3.4. ビジネスロジックとアプリケーションサービスロジック
システム開発では、問題を解決する「ビジネスロジック」と、それを実行可能にする「アプリケーションサービスロジック」があります。前者は具体的な問題解決に関わるコード、後者はシステムがスムーズに動作するためのコードです。両者は密接に関連していますが、その目的は異なります。
3.5. 現実世界とのギャップ
また、システムが現実世界の全てのニュアンスやコンテキストを完全に理解するわけではないため、必ずしも100%の問題解決ができるわけではありません。
3.6. システムの進化
システムは時間とともに進化します。新しい問題が発生した場合、それを解決するためのアップデートや改修が必要とされます。このようにして、システムは「問題解決」を継続的に行っていくものです。
「システムはすべて現実の問題を解決する」かというと、その答えは「いいえ」です。システムは多くの問題を解決する力がありますが、それは一定の制約や条件の下で行われます。そして、システム自体が解決すべき問題も進化していくため、その活動は決して一点で終わるものではありません。このような多角的な視点からシステムと問題解決の関係を理解することが、より効果的なシステム開発につながります。
4. モバイル送金の例で理解する
4.1. モバイル送金アプリの目的
モバイル送金アプリは、ユーザーがスマートフォンを使って簡単にお金を送金できるように設計されています。この状況では、主な「現実世界の問題」は「簡便かつ安全な送金手段の提供」です。
4.2. ビジネスロジックとサービスロジックの例
例えば、アプリ内での送金処理は以下のようなステップを踏むでしょう。
- 口座残高の確認
- 送金手数料の計算
- 送金処理
- データベースへの保存
- エラーメッセージまたは成功メッセージの表示
この中で、ビジネスロジックは「口座残高の確認」「送金手数料の計算」「送金処理」など、送金に直接関わる処理です。これらは現実世界で解決すべき問題に対するコードです。
一方、サービスロジックは「データベースへの保存」「エラーメッセージまたは成功メッセージの表示」など、システムがスムーズに動作するために必要な補助的な処理です。
4.3. 複雑性の管理
ビジネスロジックはしばしば複雑であり、例えば送金限度額、送金先との関係性、為替レートなど多くの要素を考慮する必要があります。これらを効率良く処理するためには、ビジネスロジックをしっかりと設計し、サービスロジックと分離する必要があります。
4.4. テスト容易性
ビジネスロジックとサービスロジックを明確に分離することで、それぞれ独立してテストが行いやすくなります。特にビジネスロジックは、ビジネスの成長と共に変更が頻繁に発生する可能性が高いため、テスト容易性は重要です。
4.5. 可読性と保守性
明確な分離は、コードの可読性と保守性を高める効果もあります。新しい開発者がプロジェクトに参加した場合でも、ロジックが分離されていればコードの理解が早く、効率的な開発が可能です。
モバイル送金の例を通して、ビジネスロジックとサービスロジックの違いとその重要性について考察しました。これらを適切に分離・設計することで、システムはより効率的に、そして柔軟に現実世界の問題に対応することができます。
5. 関心の分離とクリーンアーキテクチャ
5.1. 関心の分離（Separation of Concerns）
関心の分離は、ソフトウェア開発において非常に重要な設計原則の一つです。この原則に従うと、各部分（または「関心」）が独立しているため、一部が変更されたとしても、その影響が他の部分に及ばないようにすることができます。このようにして、ソフトウェアの保守性と拡張性が向上します。
5.2. クリーンアーキテクチャの概要
クリーンアーキテクチャは、この「関心の分離」を具現化したアーキテクチャの一つです。このアーキテクチャでは、システムをいくつかのレイヤーに分け、各レイヤーが特定の「関心」に対応するように設計します。
5.3. ビジネスロジックの中心性
クリーンアーキテクチャでは、ビジネスロジックが最も重要な「関心」であり、その他の要素（データベース、UI、外部APIなど）はすべてこのビジネスロジックをサポートするものとされます。このビジネスロジックは「エンティティ」と呼ばれる中心的なレイヤーに配置され、外部の要素はこのエンティティに依存します。
5.4. 依存性の逆転
依存性の逆転の原則もクリーンアーキテクチャに取り入れられています。これによって、高レベルのビジネスロジックは低レベルの実装詳細に依存しないようになります。具体的には、インターフェースを用いて依存性を抽象化し、ビジネスロジックのテストや再利用が容易になります。
5.5. クリーンアーキテクチャのメリット
- テスト容易性: ビジネスロジックが独立しているため、単体テストが行いやすい。
- 保守性: 各レイヤーが独立しているため、一部を変更しても他に影響が少ない。
- 拡張性: 新しい機能やレイヤーを追加する際も、既存のコードに対する影響を最小限に抑えられる。
5.6. 実践のポイント
クリーンアーキテクチャを実践する際は、各レイヤーの責任と役割を明確にして、厳格にレイヤー間の依存関係を管理することが重要です。
関心の分離とクリーンアーキテクチャは、効率的で保守性の高いソフトウェア開発を実現するための強力な手法です。これらの原則とアーキテクチャを理解し、適用することで、長期にわたるプロジェクトでもスムーズに開発を進められるでしょう。
6. まとめ
ビジネスロジックとドメインロジックは、その根底に「解決したい現実世界の問題」があり、この点で一致しています。しかし、システムを構成するコード全体を考えた場合、ビジネス的な意思決定を行うロジックと、それをサポートするロジックに分けることが重要です。この違いを理解することで、より効率的なシステム開発が可能になります。
