это да, какие такие каноны... контексты выделены и замэплены, сабдомены описаны, или же "сущности репозитории"...

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

Еще пара вопросов есть про репо, если не сложно:
1. Можно ли в репо реализовать все запросы на выборки данных (и для логики и для чтения). Очень часто видел что пишут репозитории с достаточно сложными выборками в базу. Если нельзя реализовать все запросы в репо, то норм, что доступ к хранилищу данных будет разноситься по нескольким уровням абстракции (выборки из базы и в репо и в ДАО)?
2. Видел еще реализации persistance-oriiented  Repository. Допускается ли в таких репо нетривиальные реализации внесения изменения в хранилища данных (апдейт с подзапросом в виде селекта, батч вставки)  и т.д. ?

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

> без применения всех паттернов

ну то есть если я не применил ВСЕ возможные паттерны которые за 20 лет нагенерило DDD комьюнити то "не канон"?

DDD вообще в последнюю очередь про код

> Из вещей, которые используются - слои, во, сервисы по слоям, рич модели,  единый язык, на остальное пока квалификацию после работы приходится получать

заблуждение, но не переживай, все через это заблуждение проходили

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

>  Можно ли в репо реализовать все запросы на выборки данных

Смешанный подход можно применять. Я предпочитаю сложные запросы выделять в отдельные Query, к примеру. Repository зачастую может скатиться в большую помойку из разношерстных, ничем между собой не связанных методов. Т.е. нет смысла следовать мифическому "весь доступ данных через репозиторий". Полезный takeaway из всего этого - именно четкий выделенный слой доступа данных. Т.е. условный DBA может придит, и более-менее увидеть общую картину доступа к данным. Или там - переписать какие-то запросы на сырой sql, без последующего каскада изменений по всему проекту.

Опять же - все это ситуативно

1. Можно все, но скорее всего у тебя будет нарушаться разделение ответственности и повышаться каплинг.
2. Опять же можно все - просто ты смешиваешь Table Gateway какой и Repository. Что в свою очередь приведет к нарушению кучи принципов, начинает от ISP из SOLID

в DDD лучше перестать загоняться по "слоям" и паттернам и начать загоняться по Bounded Context. Чем раньше тем лучше - какое-то время уйдет на то что бы понять как их искать. Это сложно. Важно уметь определять какие инварианты true а какие "не совсем". Для этого надо общаться с бизнесом. Потому важен единый язык - что бы ты инварианты с бизнесом и операции мог называть так как они это называют.

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

DDD is about journey (domain modeling, process modeling если хочешь, разбираться как бизнес работает) not the destination (не про код/реализацию)

"стратегический" DDD например подскажет тебе для какого bounded context твои загоны оправданы а какие "ой да похуй хоть в контроллере напрямую через SQL делай а вот ту херню вообще либо зааутсорсь либо возьми/купи готовое и не трать время на велосипеды"

поддерживаю. Я сейчас вообще хочу ввести жесткое ограничение что никаких методов кроме add/get у репозитория быть не должно. Очень редко может быть полезен какой exists/remove но это уже исключение из правил и надо доказать что это надо.

а то задолбали выборки в репозитории класть что бы одно поле потом в респонс отдать.

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

Вот без шуток я к этому пришел совсем недавно, когда начал делать +- проект серьезный (по крайней мере, для себя).
И я просто взял ActiveRecord на чтение, а Doctrine на запись. Единственный минус этого - придется поддерживать read/write запись.
Выборки я делаю прям из контроллера

нет. не могут. Если данные не нужны агрегаты для принятия решений то нечего им делать в ивентах этого агрегата.

это простой ответ*. Более сложный - "it depends". Например есть ситуации с "дополнительными таймстэмпами когда че происходит" которые не влияют на агрегат но относятся к нему.

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

Что бы небыло проблем - нужно учиться моделировать систему ивентами. С бизнесом причем. Разбираться что к чему относится и т.д. Это сложно но "кто вас просил ивент сурсинг брать"

Вы ответили на все мои вопросы...
Я только хотел спросить...

В итоге я пришел к выводу, что паттерны DDD'шные надо упоминать вместе с KISS