して注入し、実装に依存しないようにします。API)のための形式に変換することです。(例えば、集計のためのCSVになったり、管理画面向けのデータ構造になったり)からだと思います。modelの表示用のモデルへの変換機能の実装です。ドメインモデルとして必要な形式ですが、実際にユーザ画面のAPIとして欲しい形式はまた違います。タグに変換したりする必要があります。表示時点での質問者の年代(20代、30代など)さえあればよいので、現在時刻から計算して変換します。これが管理画面のAPIであればまた違うPresenterと実装が必要です。この処理が現在時刻取得の実装(システムの時刻を取得する)に依存しないようにしています。実行した時の時刻に依存しなくなるので、ユニットテストが書きやすくなります。いう意味ではDBや外部APIと同等なのでこのような命名にしています。それぞれの責務を意識すると、テスト項目が自然と決まるので迷いなくテストを書くことができます。上層から下層には依存していないので、複雑なmockを書く必要がありません。どこを変えるかが明確になるそれぞれの責務を理解していると、機能変更、追加の際にどこを直すべきか、どこは直さなくていいか、を判断しやすくなります。これは実装する人だけでなく、コードレビューする側も「この機能追加でここを変更するのはおかしい」といった指摘がしやすくなります。modelの設計も注意が必要でした。必要な情報は異なります。全情報を取得しなければならないのはコストが高いです*7。参照用もUseCaseに応じてモデルをそれぞれ用意することも検討すべきだと思いました。分離した方がいいかもしれません。以下の記事が参考になります。これはUseCaseの役割ではないか、との指摘がありました。役割になっているので、生成もUseCaseか別の層に役割を分離するのは自然だと思います。階層とpackageの位置が必ずしも一致しません。どれがどこにあるかがちょっと分かりにくいです。packageの命名と、どの層をどこに入れるかは再考の余地があります。接頭辞があった方が層を意識しやすかったと思います。hiring!Docpediaは正式リリースされましたが、まだまだこれからが本番です。一緒に開発に参加してくれる仲間を募集中です。お気軽にお問い合わせください。open.talentio.comjobs.m3.com*1:「本当の意味で」何が正解なのか今でもよく分かりません*2:すでに公開前の社内レビューでもたくさん指摘をいただきました。質問IDに間違って回答IDとかユーザIDの別の値を渡してしまう可能性が高まったら分けてもいいと思います。