✍️ はじめに
自分が今取り組んでいるプロジェクトでは、Node というエンティティがあり、それには「質問」と「回答」が含まれている。
今回実装したいのは、このNodeを受け取って「次に来そうな質問を推論する」というユースケースだ。
一見すると簡単な処理のようにも思えるが、「そのロジックをどこに書くべきか？」という問いに対して、意外なほど深い設計の思索に踏み込むことになった。
🔍 最初の構想：ユースケース層に直接ロジックを書く
最初に試みたのは、以下のようなユースケース層への直書きだった：
func (uc *createExpectedTemplateInteractor) Execute(ctx context.Context, input CreateExpectedTemplateInput) (CreateExpectedTemplateOutput, error) {
node, err := uc.nodeRepo.FindByID(ctx, domain.NodeID(input.NodeID))
// ...
if strings.Contains(node.Question(), "志望動機") {
// 次の質問を追加
}
}
このように strings.Contains を使っていくつかのルールベース推論を行い、次の質問候補を列挙して返すという構成だ。
🤔 でも、これはユースケース層の責務だろうか？
書いているうちに、ふと疑問が湧いた。
「この“次の質問を推論する”という処理は、ユースケースの責務なのか？」
クリーンアーキテクチャの原則に従えば、ユースケース層はあくまで「処理の流れ」を組み立てる場所。
「どう推論するか」まで担うのは過剰な責務ではないか？
💡 気づき：これはドメイン知識に基づく判断だ
「質問と回答の内容から、次に来そうな質問を導き出す」というのは、人間の知識や経験に基づく意味的な判断である。
つまりこれは、**ドメインロジック（意味のあるビジネス判断）**なのだ。
だから、本来この処理は エンティティにもユースケースにも属さず、ドメインサービスが担うべきだという結論に至った。
🧱 ドメインサービスとして実装する
そこで設計したのがこのインターフェース：
type QuestionInferenceService interface {
InferNextQuestions(node domain.Node) []string
}
そしてドメイン層の domain/service/question_inference_service.go に、シンプルな初期ロジックを実装した：
func (s *questionInferenceService) InferNextQuestions(node domain.Node) []string {
q := node.Question()
a := node.Answer()
if strings.Contains(q, "志望動機") {
return []string{"なぜその業界を選んだのですか？"}
}
// ...
}
これで、推論ロジックをユースケースから完全に分離できた。
🔄 そして、将来的な拡張の余地を残す
特に意識したのは、「将来この推論ロジックをAI化したくなるかもしれない」という点だ。
そこでドメインサービスをインターフェースとして定義したことが生きてくる。
将来的には、例えばOpenAIのAPIを使ったインフラ実装を用意し、次のようにDIで差し替えるだけで済む。
var svc QuestionInferenceService
if config.UseAI {
svc = infra.NewAIBasedInferenceService()
} else {
svc = service.NewQuestionInferenceService()
}
✅ ユースケース側はこうしてシンプルに
func (uc *createExpectedTemplateInteractor) Execute(ctx context.Context, input CreateExpectedTemplateInput) (CreateExpectedTemplateOutput, error) {
node, err := uc.nodeRepo.FindByID(ctx, domain.NodeID(input.NodeID))
if err != nil {
return CreateExpectedTemplateOutput{}, err
}
nextQs := uc.inferenceService.InferNextQuestions(node)
return uc.presenter.Output(nextQs), nil
}
何をするか（処理の流れ）だけに責務が限定され、読みやすく、拡張にも強くなった。
🧩 学びとまとめ
- 「この処理は“意味”を扱っているか？」と考えることで、ドメインロジックかどうかが判断できる
- ユースケースはフローを制御するだけにすることで、責務が明確になる
- ドメインサービス + インターフェース + DI の組み合わせは最強
- インフラ層での差し替えを前提に作ることで、将来の柔軟性が担保される