はじめに
アーキテクチャにおける ビジネスルール（Business Rules） は、
システムの「本質的な価値」を支える最重要部分です。
フレームワークやUI、データベースといった技術的要素は移り変わりますが、ビジネスルールは長期間にわたって変わりにくい性質を持ちます。
つまり、アーキテクチャの中心に据えるべきもの がビジネスルールです。
ビジネスルールとは
ビジネスルール = ドメインを支配するルール・手続き・制約
- 業務を遂行する上で必ず守るべき規則
- システムが存在する根拠そのもの
- 技術や環境に依存しない、不変のロジック
例
- 銀行システム: 「残高がマイナスのときは出金できない」
- ECサイト: 「在庫がゼロの商品は購入できない」
- SNS: 「ユーザー登録にはメールアドレスが必要」
ビジネスルールの分類
1. エンティティルール（Entity Rules）
- 根本的なビジネスルール
- ドメインに深く根付いている
- システムの外でも成立する規則
例:
「利息計算は年利◯％で行う」
2. ユースケースルール（Use Case Rules）
- システム固有のルール
- ユーザーとシステムのやり取りに関する規則
- システム上でのフローを支配する
例:
「ユーザーが商品をカートに入れて注文すると、在庫が減少し、注文履歴が生成される」
図解：ビジネスルールの位置づけ
- Entities（エンティティ） = 最も不変なルール
- Use Cases（ユースケース） = システム固有のルール
- UIやDB = 技術的な詳細（変わりやすい要素）
ビジネスルールは「内側」に置き、外部の変化から守る。
ビジネスルールを守る意義
-
長期的な保守性
- 技術が変わってもロジックは生き続ける
-
システムの本質を表現
- ビジネスルールがなければ「ただのCRUDアプリ」に陥る
-
テスト容易性
- ビジネスルールを独立させることで、ユニットテストが容易になる
まとめ
- ビジネスルールはシステムの心臓部
- 技術的な要素（UI/DB/フレームワーク）から隔離して守るべき
- エンティティルール（普遍的な規則）とユースケースルール（システム固有の規則）の二層で考える
良いアーキテクチャとは、変わるもの（技術詳細）から、変わらないもの（ビジネスルール）を守る構造 を持つことです。