Java 21では、スイッチのパターンマッチングが導入され、ドメイン駆動設計におけるボイラープレートコードを大幅に削減できます。これにより、複雑なオブジェクト構造をより表現力豊かで簡潔に扱うことができ、コードの読みやすさと保守性が向上します。この記事では、DDDの文脈でこの機能を活用する方法を、実用的な例とベストプラクティスを交えて探ります。
昔のやり方: 懐かしの思い出
新しい機能に飛び込む前に、なぜこのアップデートが必要だったのかを思い出してみましょう。例えば、あなたが複雑な注文処理システムを持つeコマースプラットフォームで働いているとします。ドメインモデルにはさまざまな注文状態が含まれており、それぞれ異なる処理が必要です。コードは次のようになっていたかもしれません:
public void processOrder(Order order) {
if (order instanceof NewOrder) {
handleNewOrder((NewOrder) order);
} else if (order instanceof ProcessingOrder) {
handleProcessingOrder((ProcessingOrder) order);
} else if (order instanceof ShippedOrder) {
handleShippedOrder((ShippedOrder) order);
} else if (order instanceof CancelledOrder) {
handleCancelledOrder((CancelledOrder) order);
} else {
throw new IllegalStateException("Unknown order state");
}
}
あまり見栄えが良くないですね。このアプローチは冗長でエラーが発生しやすく、正直言って退屈です。そこで、スイッチのパターンマッチングが登場します。
新しいホットな機能: スイッチのパターンマッチング
Java 21のスイッチのパターンマッチングを使うと、上記のコードをよりエレガントに書き直すことができます:
public void processOrder(Order order) {
switch (order) {
case NewOrder n -> handleNewOrder(n);
case ProcessingOrder p -> handleProcessingOrder(p);
case ShippedOrder s -> handleShippedOrder(s);
case CancelledOrder c -> handleCancelledOrder(c);
default -> throw new IllegalStateException("Unknown order state");
}
}
これこそが進化です！しかし、これがDDDにとってなぜ重要なのかを詳しく見ていきましょう。
DDD愛好者が注目すべき理由
- 表現力: パターンマッチングにより、コードがドメイン言語により近づきます。
- 認知負荷の軽減: ボイラープレートが少ないため、ビジネスロジックに集中できます。
- 型安全性: コンパイラがすべてのケースを処理していることを保証し、ランタイムエラーを減らします。
- 拡張性: 新しい状態や型の追加が容易になり、設計の進化を促進します。
実例: 注文処理の複雑さを制御する
注文処理の例を拡張して、パターンマッチングがより複雑なシナリオをどのように処理できるかを示します。注文の種類と状態に基づいて異なる割引を適用したいとします:
public BigDecimal calculateDiscount(Order order) {
return switch (order) {
case NewOrder n when n.getTotal().compareTo(BigDecimal.valueOf(1000)) > 0 ->
n.getTotal().multiply(BigDecimal.valueOf(0.1));
case ProcessingOrder p when p.isExpedited() ->
p.getTotal().multiply(BigDecimal.valueOf(0.05));
case ShippedOrder s when s.getDeliveryDate().isBefore(LocalDate.now().plusDays(2)) ->
s.getTotal().multiply(BigDecimal.valueOf(0.02));
case CancelledOrder c when c.getRefundStatus() == RefundStatus.PENDING ->
c.getTotal().multiply(BigDecimal.valueOf(0.01));
default -> BigDecimal.ZERO;
};
}
このコードスニペットは、パターンマッチングがどのように複雑なビジネスルールを優雅に処理できるかを示しています。注文の種類だけでなく、各種類内の特定の条件に基づいて異なる割引計算を適用しています。
パターンマッチングでドメインイベントを強化する
ドメインイベントはDDDの重要な部分です。パターンマッチングがイベント処理をどのように簡素化できるかを見てみましょう:
public void handleOrderEvent(OrderEvent event) {
switch (event) {
case OrderPlacedEvent e -> {
notifyWarehouse(e.getOrder());
updateInventory(e.getOrder().getItems());
}
case OrderShippedEvent e -> {
notifyCustomer(e.getOrder(), e.getTrackingNumber());
updateOrderStatus(e.getOrder(), OrderStatus.SHIPPED);
}
case OrderCancelledEvent e -> {
refundCustomer(e.getOrder());
restoreInventory(e.getOrder().getItems());
}
default -> throw new IllegalArgumentException("Unknown event type");
}
}
このアプローチにより、関心の分離が明確になり、ドメインモデルが進化するにつれて新しいイベントタイプを簡単に追加できます。
潜在的な落とし穴: すべてが順風満帆ではない
コードベース全体を書き直す前に、いくつかの潜在的な欠点について話しましょう:
- 過剰使用: すべてがスイッチ式である必要はありません。時には単純なif-elseの方が読みやすいこともあります。
- 複雑さの増加: ケースをどんどん追加したくなる誘惑があり、スイッチ文が膨れ上がる可能性があります。
- パフォーマンス: ケースが少ない場合、従来のif-elseの方がわずかに速いかもしれません（ただし、通常は差はわずかです）。
DDDにおけるパターンマッチングのベストプラクティス
- ユビキタス言語に合わせる: パターンマッチングを使用して、コードをドメインの専門家が話すように読みやすくします。
- 焦点を絞る: 各ケースはドメイン内の特定のシナリオを処理するべきです。
- ファクトリーメソッドと組み合わせる: 複雑な基準に基づいてドメインオブジェクトを作成するために、ファクトリーメソッドでパターンマッチングを使用します。
- 徐々にリファクタリングする: 一度にすべてを書き直す必要はありません。コードベースの中で最も複雑でボイラープレートが多い部分から始めましょう。
未来は明るく、冗長ではない
Java 21のスイッチのパターンマッチングは、単なる構文糖衣以上のものであり、複雑なドメインロジックを明確かつ簡潔に表現するための強力なツールです。ボイラープレートを削減し、より表現力豊かなコードを可能にすることで、開発者はビジネス要件をクリーンで保守しやすいコードに変換することに集中できます。
ドメイン駆動設計の可能性を押し広げ続ける中で、このような機能は、時には少ない方が本当に多いことを思い出させてくれます。ですから、あの厄介なif-elseチェーンをリファクタリングし、パターンマッチングのエレガンスを受け入れましょう。未来の自分（とコードレビュアー）が感謝することでしょう。
「シンプルさは究極の洗練である。」 - レオナルド・ダ・ヴィンチ
（彼は芸術について話していたかもしれませんが、私は彼がよく作られたスイッチ式も評価してくれると思いたいです。）
さらなる学び
さて、私はいくつかのスイッチ文をリファクタリングしなければなりません。コーディングを楽しんでください！