Что значит "операции с базой" ?

query разные, обращения к Repo

Если честно, то это какое-то странное разделение на схемы и так далее. Я для себя развил понимание, что схема - это не больше чем структура, которую можно записать в базу и у которой есть changeset-ы. Но это только моё мнение

У Ecto вообще нет никаких гайдлайнов и определённых практик. Я не знаю откуда ты взял что схемы нужно хранить в /schemas

Поэтому где хранить запросы - твоё личное решение. Если запросов много, то можно их хранить в Queries, я видел где-то разделение из серии

Запросы для определённой схемы хранятся в MySchema.Queries
Запросы для статистики или отчётов хранятся в Reports.Queries

В одном фениксовском проекте видел по схеме на модель и соответственно в модельке выполняются запросы

Осталось понять что такое модель...

Я имел в виду модель в MVC архитектуре

Я просто пытаюсь убедить уйти как раз от этих псевдо-моделей в текущем проекте и разделить схему данных от операций над ними.

Для одного SPA я когда-то делал реализацию в виде схемки на контроллер и в контроллере запросы

У ecto есть хорошие практики, многие из них описаны в programming ecto. Насчёт схем и функций там сказано следующее: хранить чистые функции отдельно, грязные отдельно (типа App.Repo) и тестировать отдельно. Насчёт именования каталогов там ничего нет

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

был где-то

вот как раз схему и операции над ними не следует сильно разделять, это один контекст. Следует разделять чистые фукции (Changeset/Multi f-s) и грязные (Repo.insert/update/delete/transaction). Последние специально в отдельный модуль выделены. Тестирование ченджсета - залили туфту, проверили Changeset.errors... Тестирование бд - записываем два объекта с одинаковыми именами, снова проверяем  Changeset.errors на Changeset.errors[name: ["has duplicates", _ ] |_ ] = result

сейчас модно делать не по
MDD ,а по DDD,
чему феникс теперь и следует, рекомендуя бить
границы по контекстам.

в идеале бд вообще тестировать не надо, т.к. команда экто это делает при каждом коммите. Нужно тестировать код, который в большинстве случаев описывается в App.Context.Object.changeset(t(), %{} = attrs)

В приведённом примере что ещё содержит ‘Object’ кроме ‘changeset’a?

да хоть что. Тут дело в метадологии. То, что экто пишет в базу и читает из нее правильно - не ваша зона отвественности, можно считать это априори рабочий механизм, т.к. экто сама покрыта тестами с ног до головы в пять слоев. А вот то, что вы описали в Changeset.validate_format(..)/ets тестировать нужно

ну и интегррационные тксты - отправили api запрос - получили ответ. Тут не важно сколько уровне ниже absinthe/phoenix/ecto/

Немного оффтоп. Кто пишет feature тесты?

Посоветуйте либу плз)

Вот конкретный пример: у меня есть в середине бизнес-логики query которая заканчивается Repo.update_all/2 . Как его лучше разбить и куда деть эти части?