меня всегда интересовало как AR ORM применяют на такую архитектуру, например те же дотнетичики или джависты, у них вроде Entity Framework - прям АР нативный

Так а какие?

А какой правильный?

я скинул презентацию, там на слайдах есть ссылки на доки

1. да. репозиторий это тупая коллекция которая в целом не должна много чего знать. все эти findProductsByCustomersThisYear - отдельный сервис. У репозитория только условный get, add и может быть delete/exists.
2. репозиторий хранит бизнес объекты
3. внешний слой это кто? UI? делай отдельные сервисы и возвращай то что надо для UI. репозиторий это не гейтвей к табличкам в базе

и начиная с 26 слайда важный нюанс

Обязательно ознакомлюсь

Вот как я использую Prisma, что бы работать с базой

может тебе просто не нужно с тайпскриптом все эти ООП? это ж не джава где кроме как классы и пакеты ничего для управления стэйтом и зависимостями нет

Может, отличная идея, но я просто хочу разобраться

"findProductsByCustomersThisYear - отдельный сервис"

отдельный сервис где? domain service?

"репозиторий это не гейтвей к табличкам в базе"

т.е. мы можем сделать отдельно гейтвей и репозиторий у которых будет по сути один и тот же код работы с табликами в бд (просто в репозитории персисентс домейн сущностей, а в гейтвее более общие запросы)?

ну просто в чем? "что такое ооп"? Смысл ООП в том что бы разбить стэйт системы на объекты которые его полностью контролируют. Что бы взаимодействие со стэйтом не происходило напрямую, что бы там контракты между элементами системы (то есть что внутри объекта нам глубоко насрать - нам не насрать на флоу данных в системе)

главный плюс орм
что ты работаешь с некими entity которые как обычные объекты и весь твой код работает с ними и про то как хранятся данные они знать не знают

и существуют некоторые мапперы которые могут из бд загрузить данные и вернуть сущность, или сохранить существующую сущность в бд

при этом никто не знает куда оно там сохраняет и как загружает

например информация может храниться сразу в нескольких разных бд, а ты работаешь в коде с объектом

и такое удовольствие имеет свою цену

а где хочешь. Например интерфейс может быть определен во view (там где нам нужна зависимость) а реализация в инфраструктуре. Но при этом все это просто три файлика в папке (потому что слои не папки).

> т.е. мы можем сделать отдельно гейтвей и репозиторий у которых будет по сути один и тот же код работы с табликами в бд (просто в репозитории персисентс домейн сущностей, а в гейтвее более общие запросы)?

там не будет "один и тот же код" так как скорее всего структуры данных для UI и для бизнес логики будут различаться. Если они у тебя не различаются - значит либо чо-то в декомпозиции не так либо у тебя тупой круд и че ты там вообще выпендриваешься со своими слоями.

имею ввиду что это ок будет если формировать запросики к бд будет и репо, и гейтвей?

да, ты можешь даже сделать такую штуку что у тебя репо и гейтвей внутри юзают один мэппер - реализация и того и другого это все ж ближе к инфраструктуре.

👍

ну то есть двигатель принятия решений относительно кто чего должен делать он простой - "а кому это нужно и где?"

очень часто можно встретить репозиторий на 50 методов с выборками типа findByColor, findTopSellingItems и т.д. каждый из которых юзается ровно в одном или максимум паре мест в системе.

То есть мы с таким подходом (все что про табличку в базе в репозитории) не только получаем что-то что нашурает всякие эти СОЛИДы но еще и усложняем тестирование (попробуй на такую херню потом сделать in-memory репозиторий), усложняем проект и в целом... смещаем фокус с взаимодействия объектов обратно к логическому кохижену по техническим консернам