Всем привет,
можете посоветовать хорошие Kata по DDD для начинающих, если кто знаком? )

https://github.com/ldynia/archcolider - мы
остальные:
https://github.com/lastlegion/arch-katas
https://github.com/icedhacker/architecture-katas
https://github.com/hananoyama/architectural_kata
https://github.com/lookfwd/archkata
https://github.com/selfdriventeam/kata
https://github.com/heydragon2020
https://github.com/mtykhenko/davinci-kata
https://github.com/TheJedis2020/arch_katas_2020 - 3 место
https://github.com/miyagis-forests - 2 место

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

ну вот из чата по архитектуре каты, там есть ddd-like решения

Оо, спасибооо

но как мы(точнее умные архитекторы из соседнего чата) выяснили нельзя в рамках каты адекватно сделать архитектуру т.к. нельзя погрузиться в домен, по этому их делают по примерам из своего опыта, а не по настоящему

обратно в монолит из микросервисов )

для начального "привыкания", для образа мышления по DDD - то, что надо)

Можете почитать https://github.com/ddd-crew, есть ещё emacsway если про архитектуру. Все эти люди есть в этом или том чатах, а так же Хориков и другие авторы, так что спросить есть у кого)

ок, спс👍🏼

Спасибо. А что такое сквозные ограничения?

загугли cross cutting concerns

Но это не "ограничения" же, это скорее сквозные зоны ответственности

"заботы"

заботы, зоны, проблемы - не важно, как мы решаем эти проблемы? - вводим ограничения, разграничиваем сквозные зоны

скажем, направление зависимостей внутри модулей если их много - это сквозная проблема, и мы решаем её вводя ограничения на импорты/юзинги с помощью добавления конвенций за соблюдением которых следит наш линтер/etc

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

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

в целом это как backend for frontend подходы vs какой graphql federation.

Подскажите, я правильно понимаю, что с точки зрения  CQRS Агрегаты/Репозитории нужны только для Command запросов. А для Query хватит DAO?

Если так, то если агрегаты небольшие, то плохо ли начинать с них как для query так и для command, а с ростом сложности проекта перейти на отдельные DAO для Query?