Java中級

中級 Javaで学ぶドメイン駆動設計｜アンチパターン編

 

導入

ドメイン駆動設計（DDD）は、複雑なビジネスロジックを扱う際に非常に有効なアプローチですが、実際の開発現場では多くのアンチパターンに遭遇します。これらのアンチパターンは、設計の意図を損ない、メンテナンス性や拡張性を低下させる要因となります。本記事では、特にドメイン駆動設計における典型的なアンチパターンを取り上げ、その具体的な問題点と改善策を考察します。

教科書レベルの解説（ドメイン駆動設計）

重要な概念の整理

ドメイン駆動設計は、ビジネスの核心であるドメインを中心にシステムを構築する手法です。ドメインモデルは、ビジネスルールやプロセスを表現し、これを基にソフトウェアを設計します。DDDでは、エンティティ、値オブジェクト、集約などの概念が重要です。これらを適切に扱うことで、ビジネスロジックを明確にし、開発の効率を向上させることができます。

コード例（Java）


public class Order {
    private final String orderId;
    private final List items;

    public Order(String orderId) {
        this.orderId = orderId;
        this.items = new ArrayList<>();
    }

    public void addItem(Item item) {
        items.add(item);
    }

    public double calculateTotal() {
        return items.stream().mapToDouble(Item::getPrice).sum();
    }
}

class Item {
    private final String name;
    private final double price;

    public Item(String name, double price) {
        this.name = name;
        this.price = price;
    }

    public double getPrice() {
        return price;
    }
}

コードの行ごとの解説

  1. Orderクラスは、注文を表現するエンティティです。orderIdは一意の識別子として機能します。
  2. itemsは、注文に含まれる商品のリストです。初期化はコンストラクタで行われます。
  3. addItemメソッドは、新しい商品を注文に追加するためのメソッドです。
  4. calculateTotalメソッドは、注文に含まれる商品の合計金額を計算します。

アンチパターン編

ドメイン駆動設計の実装において、しばしば見られるアンチパターンの一つは「ドメインモデルの不適切な使用」です。具体的には、ビジネスロジックがエンティティの外に散在しているケースです。このような状況では、ビジネスルールがコードのあちこちに分散し、変更が難しくなります。

例えば、上記のOrderクラスがあるとします。このクラスが計算ロジックを持つこと自体は問題ありませんが、もし計算ロジックがOrderクラスの外に置かれ、他のクラスやサービスに分散していた場合、ビジネスロジックの変更が容易ではなくなります。これにより、コードの可読性やメンテナンス性が低下し、バグを引き起こすリスクが高まります。

改善策としては、ビジネスロジックをエンティティ内に集約し、他のクラスとの依存関係を最小限に抑えることが挙げられます。具体的には、計算ロジックをOrderクラス内で完結させ、他のクラスに依存しないように設計することが求められます。

まとめ

  • ドメイン駆動設計では、ビジネスロジックをエンティティ内に集約することが重要です。
  • 散在したビジネスロジックは、メンテナンス性を低下させるため、注意が必要です。
  • エンティティの役割を明確にし、責任を適切に分配することで、コードの品質を向上させることができます。
RELATED POST