Есть такой патерн, как репозиторий. Вот по аналогии с этой

статьей хочу у себя код почистить: https://www.peterullrich.com/phoenix-contexts

Вопрос: получается в репозиторий уносить только CRUD методы? Например: создание, обновление, получение пользователя.
А допустим список всех пользователей, список пользователей с подпиской и такие прочие вещи оставлять так-же в контексте?

Бедный феникс, сколько уже ругани на эти контексты. В статье прослеживается Rails style. Особенно про servises (который в руби service object) и пример бизнес логики, где одновременно вставка в базу и отправка нотификаций. Прям очень похоже на бизнес логику в моделях в рельсе) Repo как модуль, через который идут все изменения/запросы к конкретной схеме окей. Вынос User story в некий модуль тоже окей (это command). Деление на queries/commands если очень хочется. Фильтры и прочие распихивания запросов по разным модулям - как вам удобно. Всё это как жёсткая схема с максимальным дроблением имеет мало общего с реальной жизнью. Вполне можно выбрать какие-то техники и оставить "достаточно хорошо". Пожить с ними, пересмотреть, поменять. Контексты вообще не про это. И с ними вполне удобно жить, если о них думать хоть немного во время проектирования фичей.

Ну, я могу понять автора. Хочется иметь best practices структуру, чем встречать очередной «велосипед» каждый новый проект.

В моем мире есть сервис и контекст. В контексте лежит логика связанная с базой данных, в сервисе соответственно вызывается контекст если есть комплексная бизнес логика. А запросы я вообще храню в модели (только это не модель). И соответственно вызываю в контексте (потому что работа с бд идет через контекст). Итого контроллер может вызывать либо контекст (если просто работа с бд) либо сервис. Зачем дробить сильнее - я не понимать. В такой картине phx.gen.auth делает не правильно часть с email, потому что оно должно быть в сервисе.

Хорошо было бы переписать все это. Сколько не читай - ничего не понятно(. Модель - не модель, сервис - не сервис и т.д.

А что не понятно? Сервис - это сервис. Там лежит всякая сложная бизнес-логика. В этом сервисе нету вызовов Repo.whatever,потому что эти вызовы всегда инкапсулированы в функции контекста. А модель это не модель, потому что в экто нету моделей. Но как назвать файл с чейнджсетами и defstruct по другому чтобу было всем понятно я не знаю. Так вот в этом же файле в отдельных функциях лежат всякие сложные from …join …. select … preload. Но без вызовов Repo. Потому что Repo в контексте

А сервис так и называется AnyLogicService или это модуль с названием действия по бизнес логике?

Не понятно(. Что такое контекст? Как обрабатывается запрос начиная с контроллера, какой у него маршрут? И что понимается под моделью?

Контекст это феникс контекст. Модель это схема (экто схема). > Итого контроллер может вызывать либо контекст (если просто работа с бд) либо сервис.

Слабоват я в фениксе, где-то пропустил про контекст. Все-таки контекст чего?

тогда официальную доку почитайте. Или статью, что выше кидали. Контекст это ещё один способ группировать код (который отсылает к использованию DDD)

вот это

и вот это

Посмотрел определение DDD, спасибо, вспомнил. Я читал когда-то про эти три буквы. Дело в том, что у меня и без этих прочтений сложился стиль проектировать прикладное ПО от печки, т.е. от системной модели предметной области. Привожу перечень терминов - контроллер, сервис, контекст, модель, которая не модель, запросы без вызовов Repo, потому что Repo в контексте, DDD. Как все это работает? Кто-нибудь пояснит? На простом примере, без книжек.