Господа, есть вопрос как лучше архитектурно организовать repository model и

usecase
К примеру:
есть четыре таблички в базе
- book
- publishing
- author
- written_by

связь многие ко многим

У book и author есть свои репозитории и простые методы Get, GetList, Update, Delete

Хочется написать usecase который вытащит по автору все написанные им книжки и приджойнит к каждой книжке массив в каких годах она издавалась

Как это лучше в коде организовать?

Если в классическом ORM формате сделать модель над проскими entity то я перенесу всю реляционную логику на уровень приложения, чего хотелось бы избежать
Если сделать метод в репозитории book, который будет сторить запрос с join то кажется это нарушение solid
Если сделать view на уровне базы, то это тоже может иметь какие-то последствия для дальнейшей поддержки такого приложения, но пока не знаю каких

Есть какой-то best-practice для подобных кейсов?

А что за таблица publishing?

Репозитории организуют вокруг аггрегата. Вам надо сперва расписать юзкейсы, исходя из них выбрать агрегат и потом для него спроектировать репозиторий. Который в целом может ходить за данными сразу в несколько таблиц. PS Если у вас связи многие ко многим, это уже флажок в пользу того что отдельных репозиториев там быть не может.

издания книжек, Ильф и Петров написали Золотого теленка, а потом его тиражировали в разных годах разные компании

Но разве аггрегат это не модель над несколькими плоскими сущностями хранящимися в таблице? Если я просто хочу сделать UPDATE book почему у меня не может быть отдельного репозитория над entity? ведь аггрегат может быть нужен не во всех usecase

интересно, а есть примеры проектов в открытом доступе?

и методы репозитория-агррегата могут возвращать разные модели? типа GetBook и GetAuthorsByBook будут жить в одной структуре?

У репозиториев по определению не может быть подобных методов. Репозиторий по сути это коллекция. Для выборки элемента из коллекции может использовться сложный критерий, но сути это не меняет. Хранится и извлекается из репозитория один конкретный аггрегат

На Go хз даже есть ли. Давно не слежу за этой темой. Но на .NET к примеру точно есть.

Окей, у меня есть пробелы в дизайне подобных приложений, и я все еще не могу осознать где должен жить код, который из 4 таблиц сджойнит представление, по которому можно будет итерироваться

В качестве аггрегата как правило выступает какая то сущность в рамках одного или нескольких юзкейсов. При этом надо понимать что аггрегаты и сущности могут быть описаны в коде в разных местах в разных контекстах. Т.е. если у вас есть Book сущность, это не значит что у вас на весь проект существует только одна структура Book. И вы вокруг нее строите кучу методов и функций и все рядом пихаете. Это одно из вообще самых фундаментальных заблуждений. Структур Book условных может быть много. Вплоть до того что на каждый юзкейс будет своя.

Код который абстрагирует сложную выборку данных конкретного аггрегата который собирается из разных таблиц и даже разных БД живет в репозитории. Собственно для этого паттерн репозиторий и нужен.

Прекрасно, давайте попробуем пройти top bottom Есть контракт, который обязывает возвращать модель книжек из такой ручки /api/authors/{id}/books { "books": [{«id»: 1, author: 2, pulishing: [1900, 2020, 2022]}] } спускаясь ниже обработчк ручки может вызвать usecase u.GetBooksByAuthor(id) и если я правильно понял этот запрос будет направлен в репозиторий-аггрегат а как правильно представить его модель и интерфейс в этом случае?

и здесь дополнительный вопрос «со звездочкой» будут ли проблемы если вынести аггрегат во view на уровень базы или стоит варить джоины из кода?

@antonikucherov