【要約】「10万円以上は部長承認」をどこに書くか。Goのドメインサービスと、使いすぎない線引き [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が、特定のモデルに帰属させにくい業務ルールを実装する際、設計の置き場所に迷う問題がある。例えば「金額によって承認ルートが変わる」というルールは、以下の理由で既存モデルに収まりにくい。
- ・申請モデルに組織構造を持たせると、モデルが肥大化する。
- ・承認ルートモデルに判定ロジックを持たせると、責務が不自然になる。
- ・ユースケース層に書くと、ビジネスルールがドメイン層から漏洩する。
// Approach
設計者が、モデルの責務を不自然にせず、かつビジネスルールをドメイン層に保持するために、ドメインサービスを導入する。単なる「置き場所」としての利用を避け、以下の3条件を満たす場合にのみ適用する。
- ・ドメインの知識（業務ルール）であること。
- ・特定のモデルの責務にすると不自然であること。
- ・複数のモデルや、モデル外の知識をまたぐこと。
// Result
開発者が、新しい業務ルールを追加した際、既存のドメインモデルをほぼ無傷のまま維持できた。具体的な成果は以下の通りである。
- ・既存の集約（Application）の変更は、フィールド追加などの数行に留まった。
- ・ユースケース層は、ドメインサービスを呼び出すだけの「薄い」状態を維持できた。
- ・状態を持たない関数として実装したため、DB不要で高速な単体テストが可能になった。
Senior Engineer Insight
> 実戦的な設計指針として極めて有用だ。特に「ドメインサービスを最後の手段とする」という制約は、設計の劣化を防ぐために不可欠である。Goにおいてクラスではなく関数を用いる判断も、言語の特性を活かした合理的な選択といえる。ただし、閾値の管理（ハードコードか外部注入か）といった、運用フェーズでの課題への考慮も併せて検討すべきである。