Тык, я стремлюсь написать приложение с onion-архитектурой, вот такая структура

файлов соблюдает ей?

Это больше про то, как ты будешь с ней обходится))) Вообще нормально)

Имплементация репозиториев должна быть в инфраструктурном слое. Layer это типа проект предлагается создавать? Ну +- нормально, но поверхностно

да, Layer - это проект. А есть какой-нибудь подобный проект для примера? Что имеется ввиду под поверхностно? И почему стоит отделять интерфейсы от имплементации?

Вью модели тоже хранят в domain? И эти вью модели представляют конкретные классы или выше по слоям используют интерфейсы?

+

ну получается что эти view model - это просто классы, которыми я буду оперировать в сервисах и контроллерах

А почему стоит выделять для репзиториев отдельный слой? Может их можно вместе с интерфейсами внутри DAL. Ибо дал это доступ к данным, а репозитории именно эту роль и выполняют или то что там будет лежать голый контекст с миграциями это норма?

В сервисах ты получаешь вью модель, мапишь ее в модель и швыряешь в репу?

да, звучит как будто так делать не надо)

оо, думаю так даже лучше будет, не подумал об этом

Почему, вроде нормально звучит.

https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/ Мне вот эта статья нравится. Ее можно по чуть-чуть читать, там объясняется не только как разделять, но и зачем. А это твоя картинка? Я думал, ты ее откуда-то взял.

Блин, я надеялся девушка будет в гс, эх..

а имлеминатиции лучше делать прям в проекте Persistence(DAL) или новый проект под это создавать?

можно там же

А какова задача сервисов? Они есть оберткой над репозитриями? Т.е они получают извне(с Ui) вью модели, маппят их в модели, кидают в репозитории которые сохраняют внутри базы эти смапленные модели. Но что возвращают эти сервисы?

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

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

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

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

Окей, спасибо.

!# ramazi
вот смотри, это то, что я буду возвращать из серви...

Ну смотри, StatusCode это понятие http протокола, чисто UI штука, и то, что она у тебя просочилась в абстракцию сервисного слоя это плохо. Можно ли так делать, ну наверное можно, если плюсы которые ты в этом видишь перевешивают нарушение подхода. Если забыть про статус код, можно ли завести какую-нибудь базовую модельку ответа, которая бы хранила в себе данные или сообщение об ошибке? Можно, проблемы в этом я никакой не вижу. Если захочешь попробовать избавиться от статус кода, попробуй подумать, зачем вообще ты его возращаешь. Например, я обычно разделяю 4хх и 5хх, чтобы клиент знал, стоит ли ему ретраить (4хх не стоит). Если у тебя похожий случай, в общей модельке ответа в сервисах можно было бы завести енамку "тип ошибки", например, фатальная, или временная.