ドメイン層は「業務ルールの置き場所」
前回の記事では、 MVCだけでは業務ロジックを整理しきれない理由を見てきました。
そこで登場するのが、 ドメイン層という考え方です。
ドメイン層を一言で表すなら、 業務ルールを守るための中心となる場所です。
ドメイン層が扱う「業務ルール」とは
業務ルールとは、 システムの都合ではなく、 業務として守るべき決まりごとを指します。
たとえば次のようなものです。
- 在庫が足りない場合は注文できない
- 確定した取引は取り消せない
- 金額の計算方法には決まったルールがある
これらは、 画面やDBの都合で変わるものではありません。
業務が変わらない限り、守り続けるべきルール こそが、ドメイン層の対象です。
ドメイン層は「何をしないか」が重要
ドメイン層を理解するうえで、 何をやらないかを知ることも大切です。
ドメイン層は、次のようなことを担当しません。
- 画面表示の制御
- リクエストやレスポンスの処理
- DBや外部APIへの直接アクセス
これらをドメイン層から切り離すことで、 業務ルールは 技術的な変更に影響されにくくなります。
実務では、次のような状態になっているケースがよくあります。
- 業務チェックがControllerやServiceに散らばっている
- 画面ごとに似たような判定ロジックが増えている
- 仕様変更のたびに複数箇所を直す必要がある
これらは、 業務ルールを守る場所が決まっていない ことが原因で起きがちです。
MVCのModelとの違い
ここでよく出てくる疑問が、 「それってMVCのModelと何が違うの？」 という点です。
MVCのModelは、 データと処理をまとめる役割でした。
一方、ドメイン層は、 業務ルールを守ることに 強くフォーカスしています。
実務では、 「この処理はModelに書くべきか？」 と迷う場面が多くあります。
その判断基準として、 業務として守るべきルールかどうか を考えると整理しやすくなります。
MVCは構造を整理する設計であり、 ドメイン層分離は 意味を守るための設計 と考えると分かりやすいでしょう。
なぜドメイン層を独立させるのか
ドメイン層を独立させる最大の理由は、 業務ルールを 変更しやすく、壊れにくくする ためです。
画面が変わっても、 DBの構造が変わっても、 業務ルールはそのまま使い続けられる。
これが、 ドメイン層分離の大きな価値です。
まとめ
- ドメイン層は業務ルールを守る場所
- 技術的な処理は持ち込まない
- MVCのModelとは役割の軸が違う
- 業務ルールが散らばり始めたら、ドメイン層を疑う
※ 参考：MVCの全体像から振り返りたい場合はこちら
▶ MVC学習シリーズ 目次
0 件のコメント:
コメントを投稿