発展質問：サンプルよりもやや複雑な検索処理を実装したい場合

[tenkoh]

素晴らしい書籍をありがとうございます！
実務でのGo WEBアプリケーション未経験のため、大変参考にさせて頂いております。

書籍の内容からはみ出してしまうのですが、次のような場合にはどのような実装が望ましいのか、自分で答えが出せず、こちらに質問させて頂きました。もしご意見を頂戴できれば大変ありがたいです。いや、本と関係ないので…とご回答頂いても大丈夫です🙏

実際のWEBアプリケーションでは、例えばタスク一覧に、そのユーザー名を併せて表示することがあるかと思います。
サンプルアプリケーションではDBの検索処理はTaskやUserといったエンティティ単位になっているのですが、上記のような例で素直にエンティティ単位で処理を行うと、entity.Tasksを取得し、含まれるユーザーIDについてそれぞれentity.Userを検索するN+1の状態になってしまうため、DB側でINNER JOINした結果のような新たな構造体を定義しておくことになるのかなと思っています。例えば以下のようなものです。

type TaskWithUserName struct {
    Title string
    UserName string
}

このような構造体はどのディレクトリ・パッケージに定義するのが妥当なのか、はたまたこの考え方自体がイマイチなのか、知見を頂けましたら幸いです…！

• serviceに定義する？そうするとstoreの検索処理が、entityの構造体を返すものとserviceの構造体を返すものが混在することになるが、それはどうなんだろうか…？
• entityに定義する？エンティティが乱立するような気もする…？

[budougumi0617]

ご質問ありがとうございます！お返事すぐかけるかわかりませんが && ベストアンサーがかけるかわかりませんが何でも聞いてもらってOKです！

よくも悪くもGoはあまり「ルール」がないので設計方針によるかなと思います。チーム・リポジトリの中で統一された設計思想があれば問題ないかなと思います。@tenkoh -sanに記載していただいた考え方も良いと思います！
（身も蓋もない回答でごめんなさい）。

私の場合

個人的にはパフォーマンスが問題になるまでは素朴なリポジトリの実装でservice層でデータを組み立てるアプローチでもいいかなと思います。
ただし、「タスクをユーザー名で検索する」みたいな検索条件を実装する必要がある場合はJOINする一択になるかなとは思います。

考えたこと

そのうえで思いついたいくつかのアプローチとメリデメ並べると以下のような感じでしょうか。

どこでデータを組み合わせるか

• ロジック層(service pkg, usecase pkg etc...)で組み合わせる
  • メリット: SQLの実装はシンプルに保てる
  • デメリット: 関連エンティティが多いとそれぞれでデータを取得する必要がある
  • デメリット: パフォーマンスが良くない
  • デメリット: 「検索条件」の実装はまずできない
• リポジトリ層（repository pkg, store pkg, datastore pkg etc...）で組み合わせる
  • メリット: 冗長なDBへのアクセスやデータ取得をせずにすむ
  • メリット: 検索の実装をするとき、絞り込みをSQLで実装できる
  • デメリット: ユースケースごとに実装を用意するとメンテするSQLがどんどん増えてしまう
  • デメリット: ロジックがstore層に入り込んでしまう可能性がある
  • デメリット: GORMなどのORM系のライブラリを使っているとJOINするときにライブラリの制約を受けやすい

どこに構造体を定義するか

• ロジック層(service pkg, usecase pkg etc...)で定義する
  • 「特定のシナリオに対するデータ表現なのでサービス層」という解釈
• リポジトリ層（repository pkg, store pkg, datastore pkg etc...）で定義する
  • リポジトリ層でデータを組み合わせたらリポジトリ層でつくられたデータ構造という解釈
• 他の層に依存していない別の層（entiry pkg etc...)で定義する
  • データを受け渡したりするときに循環インポートでめんどくさいことになる可能性をなくすためのアプローチ
• 専用の構造体は用意しない
  • gRPCなりOpenAPI(Swagger)で自動生成したレスポンス用の構造体があるパターンなど
  • たとえば埋込み型を使ってhandler層などでレスポンスを加工するアプローチ

type TaskDetail {
	Task
	User
}

func buildRespose(tds []TaskDetail) OpenAPIとかで自動生成したレスポンス型 {
	// TaskDetailからタスクタイトルとユーザー名が入ったリストを作る
}

その他

entity.Tasks を取得し、含まれるユーザーIDについてそれぞれ entity.User を検索するN+1の状態になってしまう

ちなみに、こちらに関しては例えば以下の書き方をすればN+1にはならないかなと思いました。

package server

import "github.com/samber/lo"

func (s *service) ListTaskWithUserName() ([]TaskWithUserName, error) {
	tasks, err := s.taskRepo.All()
	if err != nil {
		return nil, err
	}
	userIDs := lo.Map(tasks, func(t Task, _ int) string { return t.UserID })
	users, err := s.userRepo.List(userIDs)
	if err != nil {
		return nil, err
	}
	userMap := lo.SliceToMap(users, func(u User) (string, User) { return u.ID, u })
	var results []TaskWithUserName
	for _, task := range tasks {
		result := TaskWithUserName{Title: task.Title}
		if u, ok := userMap[task.UserID]; ok {
			result.UserName = u.Name
		}
		results = append(results, result)
	}
	return results, nil
}


type User struct {
	ID   string
	Name string
}

type UserRepo interface {
	List([]string) ([]User, error)
}

type Task struct {
	ID     string
	Title  string
	UserID string
}
type TaskRepo interface {
	All() ([]Task, error)
}

type TaskWithUserName struct {
	Title    string
	UserName string
}

type service struct {
	userRepo UserRepo
	taskRepo TaskRepo
}

[tenkoh]

お返事を下さりありがとうございます。
なるほど、いろいろなパターンを考え得るのだな、ということが分かりました…！
頂戴した内容を咀嚼して、試行錯誤してみたいと思います…！
大変参考になりました…！感謝申し上げます…！