В основном все как-то о теории говорят.

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

CQRS же очень простая идея о том, что по возможонсти операции чтения и записи следует разделять

идея простая, но дает кучу вариантов для дальнейших выдумок

вроде read only model и т.д.

главное не перепутать CQRS и булшит вроде command/query bus

последнее можно воспринимать как очень частный случай CQRS

То есть зачастую Command Bus — лишняя абстракция?

она налагает весьма жесткое ограничение - хэндлер команды ничего не может возвращать

это как бы... не особо большая проблема, но.... как по мне оверхэд

с другой стороны хоть как-то стандартизированный споосб работы с данными

Ну, это известно.

а вот query bus это уже булшит

А что это вообще?

ну это кк command bus но для операций чтения)

меня последний месяц не покидает ощущение что основная проблема... это то что command это обычно уровень приложения, а query вообще по сути к UI layer относится больше

Хм. Ну, а если у меня такая ситуация, что корень предполагаемого агрегата тянет данные из разных источников? Как быть?

Скажем, сейчас это могут быть даже разные базы данных.

у твоего корня агрегата есть некий репозиторий, который вытянет его тебе весь

слазает в разные базы данных, слепит из данных агрегат и вернет корень

это не совсем "операция на чтение"... ну тоесть.. если бы твои агрегаты тупо валялись бы в памяти, у тебя было бы меньше путаницы как по мне

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

у твоего корня агрегата есть некий репозиторий, который вытянет его тебе весь

То есть я внутри одного репа могу свободно лезть в другие БД (сырыми запросами) или использовать другие репозитории как зависимости?

То есть я внутри одного репа могу свободно лезть в другие БД (сырыми запросами) или использовать другие репозитории как зависимости?

да, вполне

> другие репозитории как зависимости? 99% что этого не будет

либо для тебя "репозиторий" = table gateway

что не то же самое

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

На самом деле, есть условия, когда не надо подгружать все данные. Например, если компания скрыта.

На самом деле, есть условия, когда не надо подгружать все данные. Например, если компания скрыта.

не понял

можешь пояснить?

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

ну так у тебя компания и есть корень агрегата

ты просто его весь не грузишь

и опять же - когда мы говорим про "отображать" агрегаты мы забываем и тупо делаем выборку из базы

с теми данными которые нам нужны

репозитории - только для бизнес логики

если тебе надо "что-то найти" то это уже задача других штук (назовем их файндерами)

в этом соль разделения

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

короч ладно

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

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

Накинь, накинь. Интересно и полезно)

она налагает весьма жесткое ограничение - хэндлер команды ничего не может возвращать

Это не совсем так

Команды которые ничего не возвращают это мало удобно, просто они чаще всего не могут вернуть сразу все, например новую сущность, потому что операции асинхронные. Команда в таком случае вернёт uuid, а вы новым запросом можете получить всю инфу

Сама суть command bus в том, что хендлер команды ничего не возвращает, а сама команда — DTO.

Если используется UUID, то его можно сгенерить заранее. Ну, а как быть с обычными айдишниками, фиг знает)

Сама суть command bus в том, что хендлер команды ничего не возвращает, а сама команда — DTO.

Тогда это достаточно бессмысленная команда

Почему?

Я что-то сделала, но что никому не скажу

Иди и догадайся

А как же соглашения об именовании?)

Так можно и про методы save/delete сказать. Хрен знает, что они под капотом делают)

А как же соглашения об именовании?)

Что-то добавилось, как ты найдёшь что именно?)

Нужен конкретный пример. Не совсем понимаю, о чем речь.

Делаешь добавление пользователя

Твоя команда ничего не возвращает

Как потом его открыть?

Новым запросом?

Куда?

В секунду добавляется 100 пользователей

Какого искать?

Ну добавилось 100 пользователей. А что с ними дальше надо делать?

Тебе надо открыть того, что ты только что добавил

При этом другие люди добавляют других пользователей

Это могут быть например заявки какие-то

А не пользователи

А если что-то пошло не так?

ERROR: S client not available

Ты об этом никогда не узнаешь?

Ну вот насчёт открытия нового не знаю, честно)) а по поводу каких-то ошибок. Можно же исключения использовать.

И соответствующие обработчики.

Как вариант, редирект на какую-то страницу с ошибкой.

Вот ты отправил запрос, команда ничего не возвращает (ошибки тоже)

Произошла ошибка

Что дальше?

Выкинуть исключение

Команда же не возвращает ошибку?

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

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

Команды которые ничего не возвращают это мало удобно, просто они чаще всего не могут вернуть сразу все, например новую сущность, потому что операции асинхронные. Команда в таком случае вернёт uuid, а вы новым запросом можете получить всю инфу

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

А зачем её возвращать. Она же может кинуть исключение. И попутно зафигачить событие, логи

А зачем её возвращать. Она же может кинуть исключение. И попутно зафигачить событие, логи

Чем throw от return отличается?)

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

Это про формирование сложной модели

Чем throw от return отличается?)

Тем, что прерывает нормальное выполнение сценария))

где граница сложности?

где граница сложности?

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

Когда понимание предметной области требуют получения образования и много лет опыта работы в сфере

Когда понимание предметной области требуют получения образования и много лет опыта работы в сфере

Как пример

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

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

А пост в блоге и сам блог это очень простая модель

даладно?! кто может править пост? в какой момент нужно отображать пост

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

Если нужна модель уровня школьной, то тоже ещё вопрос нужно ли

На гитхабе есть пример DDD на Java. Там не используется Command Bus, но фасад, который возвращает идентификатор для последующего использования.

citerus/dddsample-core.

2+2 тоже выглядит просто. а за + стоит нехилая модель

С телефона замучаюсь ссылку писать.

даладно?! кто может править пост? в какой момент нужно отображать пост

Вопрос дальше в сложности кода и приложения, процедурный скрипт на 100 строк или объектная модель

И как по мне, там все это довольно интересно реализовано.

Все упрется в стоимость разработки и дальнейшей необходимости поддержки

2+2 тоже выглядит просто. а за + стоит нехилая модель

Ага, где-то был калькулятор на пхп

Сделанный правильно