Спасибо за отлично подобраную информацию в одном месте
А на английском нету?

Нету

на dto похоже, смотря для чего это надо

Приветствую. Не могу уловить мысль. Ну вот есть задача "сделать что-то с объектами имеющими вот такой признак". Это не UI. Делать под это дело отдельный репозиторий? Или что?

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

ну либо абстрагироваться прям до талого через квериобжекты, но чаще всего просто лень писать больше кода

а чтобы более "луковично" / "гексагонально" было, написал просто чуть-чуть кода и пропатчил внутренние сервисы EF, чтобы всю херню, которая конфижит миграции / бд и прочую дичь (аки контекст - фабрики, энтити конфигурации и прочее), хранить вообще отдельно и в проекте никогда её не видеть в неположенных местах

Ну вот опиши реальный кейс такой. Или ты больше кейс с table gateway описываешь?

Ну например. Есть табличка на заказы пиццы. У каждой пиццы есть кнопочка "Отправить на кухню", ручная отправка менеджером. Т.е. в следующющий контекст. Приходит таска: сделать кнопочку, чтобы на кухню отправлялись пиццы у которых уже поджимает время , так как менеджер не успевает.  Натянуто но все же.
Т.е. какие то массовые операции над сущностями по фильтру.

Ну в контроллере достаём список id и отправляем десять команд для каждой пиццы

По фильтру находишь айдишки, потом операции над айдишкой. Все что больше этого специфичные кейсы где прям надо полноценный батч процессинг

Согласен, но где то сначала же надо этот список получить. Т.е. нужно отдельный сервис который просто ids находит?

Да, отдельный сервис

@fes0r  @elisdn Спасибо :)

Где писать правила для view которые зависимы от внутренностей модели но никак не являются бизнес правилами?
У меня онлайн-карта и событие полного обновления каждый час.
Объекты на карте отображают состояние части системы.

В чем прелесть view - они не меняют стэйт системы. А значит можно просто читать где хочешь и как хочешь

По сути в твоём случае у тебя view model - может это сделает "бизнес логику во вью" не такой коребящей так как это просто другая модель

т.е. в модели которую использует только view, я могу делать проверки которые нужны view?  т.е. view задает контракты а не наоборот?

мне например нужно апи сделать отдельным модулем и в нем же read model.
а реализацию апи уже в основном модуле. такой кейс имеет место быть или я хрень пишу?)

ты когда на работу устраиваешься тебе предлагают подписать контракт. Ты можешь отказаться.

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

Модель оптимальная определяется тем для чего она тебе. Если тебе для view - ты можешь строить под нее свою модель да. Особенно если это чет такое специфичное как ты описываешь