Laravel プロジェクトが成長するにつれて、物事が少し手に負えなくなり始めていると感じたことはありますか?コントローラーは肥大化し、モデルは過剰な機能を実行し始め、コードベースは突然、何か月も整理しようと思っていた引き出しのようなものになってしまいます。ここで、ドメイン駆動設計 (DDD) が介入して、作業を簡素化できます。

DDD は、アプリケーションの構造が現実世界で解決している問題と密接に一致するようにアプリケーションを設計する方法です。これにより、プロジェクトの成長に合わせてコードがよりクリーンになり、よりスケーラブルになり、管理が容易になります。

このガイドでは、Laravel での DDD の基本を説明し、その実装方法を説明し、途中で実際の例をいくつか示します。

目次

1. ドメイン駆動設計 (DDD) とは何ですか?
2. Laravel で DDD を使用する理由
3. DDD のコンポーネント
   • エンティティ
   • 値オブジェクト
   • リポジトリ
   • サービス
4. LaravelでのDDDの実装
   • 例 1: 注文管理システムの構築
   • 例 2: ユーザー サブスクリプションの管理
5. Laravel における DDD の長所と短所
6. 最終的な考え

ドメイン駆動設計 (DDD) とは何ですか?

Laravel の詳細に入る前に、ドメイン駆動設計 (DDD) とは何なのかを説明しましょう。 DDD は、ソフトウェアが解決している中核的な問題である ビジネス ドメイン に焦点を当ててアプリケーションのコードを整理する方法です。

コントローラーやモデルなどの技術的な概念を中心にコードを構造化するのではなく、

現実世界の概念を中心にコードを構造化します。これは、アプリケーションの動作に応じて、注文、製品、顧客などになります。

一言で言えば、DDD は現実世界のプロセスを反映するアプリケーションの構築に役立ち、特にコードが成長するにつれて、コードの理解と保守が容易になります。

Laravel で DDD を使用する理由

Laravel がデフォルトで使用する MVC (Model-View-Controller) パターンに精通している場合は、それがほとんどのアプリケーションでうまく機能することがわかります。しかし、アプリケーションがスケールするにつれて、MVC パターンによって相互依存するコードが混乱する可能性があります。

ドメイン駆動設計は、アプリケーションの拡張と長期にわたる保守を容易にすることで、この問題を解決します。

DDD は、

ビジネス ロジックを インフラストラクチャ コードから分離します。これは、アプリケーション ロジックがデータベースや API などに結び付けられないことを意味し、後でテクノロジーを簡単に交換できるようになります。

DDD のコンポーネント

DDD がどのように機能するかを理解するには、その主要なコンポーネントを知る必要があります。それらを詳しく見てみましょう:

エンティティ

エンティティは、明確な ID を持つドメイン内のオブジェクトです。たとえば、各注文は一意であるため、注文はエンティティになります。

// app/Domain/Order/Order.php クラスの順序 { プライベート $id; プライベート$ステータス; パブリック関数 __construct($id, $status) { $this->id = $id; $this->ステータス = $ステータス; } // ゲッターおよびその他のビジネス ロジック }

// app/Domain/Order/Order.php
class Order {
    private $id;
    private $status;

    public function __construct($id, $status) {
        $this->id = $id;
        $this->status = $status;
    }

    // Getter and other business logic
}

値オブジェクト

値オブジェクトは、アイデンティティを持たないオブジェクトですが、概念を表します。たとえば、Money オブジェクトは値を表しますが、一意の ID は必要ありません。

// app/Domain/Order/Money.php クラスお金{ プライベート $amount; プライベート $currency; パブリック関数 __construct($amount, $currency) { $this->amount = $amount; $this->currency = $currency; } パブリック関数 getFormatted() { "{$this->金額} {$this->通貨}" を返します。 } }

// app/Domain/Order/Order.php
class Order {
    private $id;
    private $status;

    public function __construct($id, $status) {
        $this->id = $id;
        $this->status = $status;
    }

    // Getter and other business logic
}

リポジトリ

A

Repository は、エンティティなどのドメイン オブジェクトの取得と永続化を処理します。ドメイン オブジェクトがデータベースと直接やり取りするのではなく、リポジトリがデータ アクセスを管理します。

// app/Domain/Order/OrderRepositoryInterface.php インターフェース OrderRepositoryInterface { パブリック関数 findById($id): ?Order; パブリック関数 save(Order $order): void; } // アプリ/インフラストラクチャ/オーダー/EloquentOrderRepository.php class EloquentOrderRepository は OrderRepositoryInterface を実装します { パブリック関数 findById($id): ?Order { // Eloquent を使用して注文を取得する } public function save(Order $order): void { // Eloquent を使用して注文を保存する } }

// app/Domain/Order/Order.php
class Order {
    private $id;
    private $status;

    public function __construct($id, $status) {
        $this->id = $id;
        $this->status = $status;
    }

    // Getter and other business logic
}

サービス

サービスは、注文の作成や支払いの処理などのビジネス ロジックを処理します。このロジックをコントローラーに入れる代わりに、サービスにカプセル化します。

// app/Domain/Order/CreateOrderService.php クラス CreateOrderService { パブリック関数実行($data) { $order = new Order($data['id'], $data['status']); // 注文を作成するためのビジネス ロジック } }

// app/Domain/Order/Order.php
class Order {
    private $id;
    private $status;

    public function __construct($id, $status) {
        $this->id = $id;
        $this->status = $status;
    }

    // Getter and other business logic
}

LaravelでのDDDの実装

主要なコンポーネントを理解したところで、実際の例をいくつか挙げて、Laravel で DDD を実装する方法を見てみましょう。

例 1: 注文管理システムの構築

電子商取引サイト用の

注文管理システム を構築しているとします。 DDD がコードの整理にどのように役立つかは次のとおりです:

1. エンティティ: ID やステータスなどの属性を使用して、各注文を表す Order エンティティが必要になります。
2. 値オブジェクト: 価格を表す Money 値オブジェクトを作成できます。
3. リポジトリ: 注文を取得してデータベースに保存するには、OrderRepository を作成します。
4. Services: CreateOrderService は、新しい注文を作成するためのロジックを処理します。

基本的なフローは次のとおりです:

// app/Http/Controllers/OrderController.php クラス OrderController { プライベート $createOrderService; パブリック関数 __construct(CreateOrderService $createOrderService) { $this->createOrderService = $createOrderService; } パブリック関数ストア(リクエスト $request) { $this->createOrderService->execute($request->all()); return response()->json(['メッセージ' => '注文が作成されました!']); } }

// app/Domain/Order/Order.php
class Order {
    private $id;
    private $status;

    public function __construct($id, $status) {
        $this->id = $id;
        $this->status = $status;
    }

    // Getter and other business logic
}

例 2: ユーザー サブスクリプションの管理

SaaS プラットフォームの

ユーザー サブスクリプション を管理していると想像してください。 DDD を使用すると、次のように作成します:

各ユーザーのサブスクリプションを表すサブスクリプション エンティティ。
サブスクリプション期間を管理するための期間値オブジェクト。
データ アクセスを処理する SubscriptionRepository。
サブスクリプションの更新などのビジネス ロジックを処理する SubscriptionService。

サブスクリプション更新の処理方法は次のとおりです:

// app/Domain/Subscription/RenewSubscriptionService.php クラス RenewSubscriptionService { プライベート$subscriptionリポジトリ; パブリック関数 __construct(SubscriptionRepositoryInterface $subscriptionRepository) { $this->subscriptionRepository = $subscriptionRepository; } パブリック関数 renew($subscriptionId) { $subscription = $this->subscriptionRepository->findById($subscriptionId); $subscription->renew(); $this->subscriptionRepository->save($subscription); } }

// app/Domain/Subscription/RenewSubscriptionService.php
class RenewSubscriptionService {
    private $subscriptionRepository;

    public function __construct(SubscriptionRepositoryInterface $subscriptionRepository) {
        $this->subscriptionRepository = $subscriptionRepository;
    }

    public function renew($subscriptionId) {
        $subscription = $this->subscriptionRepository->findById($subscriptionId);
        $subscription->renew();
        $this->subscriptionRepository->save($subscription);
    }
}

---

LaravelにおけるDDDの長所と短所

長所:

• より良い組織: コードはドメインを中心にきちんと構造化されています。
• スケーラビリティ: 大規模なアプリケーションの拡張と管理が容易になります。
• 保守性: ビジネス ロジックはインフラストラクチャの問題から分離されています。

短所:

• 学習曲線: DDD には新しい概念が導入されており、最初は圧倒されるかもしれません。
• 小規模プロジェクトのオーバーヘッド: 小規模で単純なプロジェクトに DDD を実装するのはやりすぎのように感じるかもしれません。

---

最終的な考え

Laravel での DDD は難しそうに思えるかもしれませんが、技術層ではなくビジネス ドメインの観点から考え始めると、意味が分かり始めます。プロジェクトの成長に合わせて、コードをクリーンで保守しやすく、スケーラブルに保つことがすべてです。

小さなことから始めましょう。 DDD 原則を使用してアプリ内の 1 つの機能をリファクタリングし、それがどのように感じられるかを確認してください。時間が経つにつれて、組織とそれがもたらす明快さを理解できるようになります。

頑張ってコーディングしてください!