DDD（ドメイン駆動設計）を導入すると、業務ルールをコードで表現しやすくなり、変更に強いシステムを作れると言われています。しかし、実際に開発を始めると「業務フローを1つのクラスにまとめてよいのか」「どこにロジックを配置すればよいのか」と悩む場面が多くあります。この記事では、DDDで業務ロジックを設計するときの考え方や、ありがちな設計ミス、適切な責務分割について解説します。
DDDは簡単に作れる設計手法ではなく、複雑な業務を整理するための考え方
DDDは「業務知識をソフトウェアの構造に反映させる」ための設計手法です。そのため、単純なアプリケーションでは導入効果を感じにくい場合があります。
例えば、単純な登録画面だけのシステムであれば、データを保存するだけでも十分です。しかし、配車業務のように「車両の空き状況」「配送条件」「担当者判断」「外部システム連携」など複数のルールが絡む場合、DDDの考え方が役立ちます。
つまりDDDはコード量を減らしたり、最初から簡単に作れる方法ではなく、後から業務変更が発生したときに対応しやすくするための設計方法です。
業務フローを1つの巨大なクラスにまとめる問題点
業務フローを表現しようとして「出庫」という1つのクラスを作り、その中に出庫伝票作成、配車、外部連携などすべての処理を入れる設計は、一見すると業務をそのまま表現しているように見えます。
しかし、時間が経つにつれてそのクラスは大きくなり、多くの責務を持つようになります。DDDでは、このような状態を避けるために「1つのオブジェクトが何を担当するべきか」を重要視します。
例えば、出庫という業務を考えた場合でも、以下のように役割を分けられます。
| 役割 | 担当する処理例 |
|---|---|
| 出庫エンティティ | 出庫状態や業務ルールの管理 |
| 伝票番号生成サービス | 番号発行ルールの管理 |
| 配車サービス | 車両割り当てや配車判断 |
| 外部連携サービス | 他システムへの通知処理 |
このように業務上の意味ごとに責務を分割すると、変更時の影響範囲を小さくできます。
DDDにおける業務ロジックの置き場所の考え方
DDDでよく悩むポイントが「この処理はどこに書くべきか」という問題です。基本的には、そのルールがどの概念に属するかを考えると判断しやすくなります。
例えば、出庫伝票そのものが持つべきルールであれば、出庫エンティティに配置します。「出庫済みの場合は変更できない」といった状態管理は、出庫自身が知っているべき情報です。
一方で、伝票番号の採番のように出庫だけでは完結しない処理は、専用のサービスとして切り出すことが一般的です。
例として「202608060001」のような番号を作成するルールがあり、日付や連番管理、他システムとの重複確認が必要なら、出庫クラスではなく採番サービスの責務になります。
ドメインサービスを使うべきケースとは
DDDでは、エンティティや値オブジェクトだけでは表現しづらい業務ルールをドメインサービスに配置します。
例えば「最適な車両を選択する」という処理は、出庫だけの責務とは言い切れません。複数の配送条件や車両情報を比較する必要があるため、配車サービスというドメインサービスとして表現するほうが自然です。
重要なのは、単純に処理を別クラスへ移動することではなく、その処理が業務上どの概念に属しているかを考えることです。
DDDで失敗しやすい設計パターン
DDDを始めたばかりの場合、すべての処理をドメイン層へ入れようとしてしまうケースがあります。しかし、外部API呼び出しやメール送信、データベース操作などはドメインモデルとは異なる責務です。
例えば「出庫完了後に外部配送システムへ通知する」という処理では、出庫完了という業務判断はドメイン層に置きますが、HTTP通信処理自体はインフラ層など別の場所で管理します。
また、DDDの形を真似ること自体が目的になると、かえって複雑なコードになることがあります。大切なのは、業務変更に対応しやすい構造になっているかという点です。
DDDを導入するときは小さな単位から整理する
DDDを実践するときは、最初から完全な設計を作ろうとするより、変更が多い業務部分から整理していく方法が効果的です。
例えば配車システムであれば、「配車判断」「出庫状態管理」「伝票番号管理」など、業務ルールが多い部分からドメインモデル化すると理解しやすくなります。
実際の開発では、最初から完璧な境界を決めることは難しいため、業務理解が深まるにつれてモデルを改善していくこともDDDの重要な考え方です。
まとめ｜DDDは作りやすさよりも変更への強さを重視する設計
DDDは単純に開発を楽にする方法ではなく、複雑な業務ルールを整理し、将来的な変更に対応しやすくするための考え方です。
業務フローをすべて1つのクラスにまとめる方法は、初期段階では分かりやすくても、規模が大きくなると責務が集中して管理が難しくなる可能性があります。
出庫、配車、採番、外部連携など、それぞれの業務上の意味を考えて適切に分割することで、DDDのメリットを活かした保守しやすいシステム設計につながります。
コメント