ビジネスロジックとは？（ビジネスロジック）意味・特徴をわかりやすく解説

Q: ビジネスロジックとは？

アプリケーションの中核となる業務処理ロジック。「料金計算」「在庫管理」「ユーザ権限」等のビジネスルールをコード化した部分で、Clean Architecture では Domain 層に配置される。

概要

ビジネスロジック（Business Logic / Domain Logic）は、アプリケーションの中核となる業務処理ロジックを指す。「ECサイトの送料計算」「銀行の利息計算」「在庫減算ルール」「ユーザ権限判定」等、ビジネスドメイン固有のルールをコード化した部分である。2026 年現在、Clean Architecture / Hexagonal Architecture / Onion Architecture / DDD（ドメイン駆動設計）が業界標準アプローチとして広く採用され、ビジネスロジックを フレームワーク・データベース・UI から独立させる ことで、テスタビリティ・保守性・移植性を確保する設計思想が主流である。

主要アーキテクチャパターン（2026 年）

Clean Architecture（Robert C. Martin）

[ Presentation ] → [ Application / Use Case ] → [ Domain / Entity ]
                                                  ↑
[ Infrastructure / DB / API ] -------------------+

依存関係は内向き（Domain が他に依存しない）
ビジネスロジックは Domain + Use Case 層に集約
DB / Web フレームワークは Infrastructure / Presentation の差し替え可能要素

Hexagonal Architecture / Ports and Adapters

[ Driving Adapter (HTTP / CLI) ] → [ Port (Interface) ] → [ Domain ]
                                                            ↓
[ Driven Adapter (DB / API) ]   ← [ Port (Interface) ] ←

DDD（ドメイン駆動設計）

概念	役割
Entity	ID で同一性を持つドメインオブジェクト
Value Object	不変の値（金額 / 日付 / 住所）
Aggregate	整合性境界、Entity + VO の集合
Repository	永続化の抽象化
Domain Service	Entity に属さないビジネスロジック
Use Case	アプリケーション層、ユーザの行動単位

TypeScript で書いた例（Clean Architecture）

// Domain Entity
export class Order {
  constructor(
    public readonly id: OrderId,
    public readonly items: OrderItem[],
    private status: OrderStatus,
  ) {}

  // ビジネスルール: キャンセルは Pending 状態のみ可
  cancel(): void {
    if (this.status !== OrderStatus.Pending) {
      throw new DomainError('Only pending orders can be cancelled');
    }
    this.status = OrderStatus.Cancelled;
  }

  // ビジネスルール: 合計金額計算
  totalAmount(): Money {
    return this.items.reduce(
      (sum, item) => sum.add(item.subtotal()),
      Money.zero(),
    );
  }
}

// Use Case
export class CancelOrderUseCase {
  constructor(private orderRepo: OrderRepository) {}

  async execute(orderId: string): Promise&lt;void> {
    const order = await this.orderRepo.findById(orderId);
    if (!order) throw new NotFoundError('Order not found');
    order.cancel();
    await this.orderRepo.save(order);
  }
}

各層の責務

層	責務	依存
Domain	ビジネスルール、Entity、VO	なし（最内層）
Application（Use Case）	ユーザの行動単位、Domain を組合せ	Domain のみ
Infrastructure	DB / API / 外部サービス実装	Domain Repository Interface
Presentation	HTTP / GUI / CLI	Application

ビジネスロジックを Domain に集約する利点

テスタビリティ: DB / Web 不要で純粋単体テスト可能
可読性: ビジネスルールが 1 ヶ所に集中、変更時の影響範囲明確
再利用: 同じドメインで Web / CLI / Mobile 全部に対応
DB 切替: PostgreSQL → DynamoDB 等への移行が Infrastructure 層の差し替えのみで完了
フレームワーク独立: Express → Hono → Fastify 等を入れ替え可能

アンチパターン（避けるべき）

トランザクションスクリプト: コントローラに全部書く、テスト困難
Anemic Domain Model: Entity がただのデータ持ち、ロジック散在
God Class: 1 つのクラスに数千行、責務不明
Database-Driven Design: テーブルがそのまま Entity、ドメインモデル不在
Service オブジェクトの過剰使用: ロジックが Service に流出、Entity 空洞化

自作 PC / 個人開発との接点

個人 SaaS 開発: 副業 SaaS でも Clean Architecture 推奨、長期保守性が圧倒的に違う
学習リソース: Robert C. Martin "Clean Architecture" 書籍、Eric Evans "Domain-Driven Design" 書籍
TypeScript 実装: jisaku.com も Clean Architecture 採用（Domain / Application / Infrastructure / Presentation 4 層）
テストフレームワーク: Vitest / Bun Test / Jest で Domain 層をピュア単体テスト

用語	違い
ロジック層	より広い概念、ビジネスロジックは特に業務固有部分
バリデーション	入力検証、ビジネスロジックは業務ルール
ワークフロー	多段プロセス、ビジネスロジックは個別判定
アルゴリズム	計算手順、ビジネスロジックは業務適用

よくある質問

Q1: 個人開発で Clean Architecture は過剰？ A: 学習目的なら有効。本格的な SaaS / B2B プロダクトを目指すなら 1 年後の自分が感謝する。スクラッチプロトタイプは MVC で十分。

Q2: ビジネスロジックを ORM のモデルクラスに書くのは？ A: 推奨されない。Active Record パターンは小規模では便利だが、複雑化すると Domain と Persistence が混じる。Repository パターンで分離が王道。

Q3: TypeScript で DDD する際の落とし穴は？ A: (1) Class より Interface 中心になりがち、(2) Generic で過度に汎用化、(3) Decorator 多用で読みにくく。シンプルな class + 純粋関数が最適バランス。

まとめ

アプリの 業務ルールをコード化した中核部分
2026 年は Clean Architecture / DDD が業界標準アプローチ
Domain 層集約 + テスタビリティ確保 が長期保守性の鍵

ビジネスロジック（ビジネスロジック）

概要