Например, чтобы уложить данные для чтения специальным образом. Или, чтобы отделить нагрузку. Или, чтобы не долбать мастер систему, а иметь копию данных у себя.
то будет просматривать эти данные в Outbox и вызывать юз кейсы для изменения каждого агрегата.
А если архитектура монолитная - то как?
А в чём проблема? На аутбокс событие есть подписчик, который дёргает юскейс.
А как сделан подписчик не так уж важно: может напрямую из БД читает, может через очередь из дибезиума получает.
Меня больше волнует вопрос: зачем городить хореографию, если это всё всё одна бизнес-операция в рамках одной БД и можно просто обработать в транзакции.
Запрашивать объяснение сложных решений, чтобы лучше понимать логику ответа модели.
Вот с этого угарнул.
Попросите модель умножить 123456 * 43223, потом попросить объяснить как она это посчитала. Она будет выдумывать, потому что она не знает, как она это сделала. Проще говоря - врать.
Для нейронки её же ответы - это внешние данные из контекста, она вообще за них не отвечает. Тем более, что контекст можно положить что угодно.
с использование конструкторов или стат методов агрегата.
Нужно будет защититься, чтобы кто угодно не мог собрать что угодно. Я бы не хотел валидироваться при каждой сборке объекта из БД.
Как собрать - я понял, а как сохранять без ченж трекинга? Я вижу 2 варианта: сохранять всё или знать снаружи, что нам нужно сохранить. Может знаешь как проще?
Я просто довольно долго работал с даппером (мой пр в даппер) и сохранение было больным местом. Нужно знать что сохраняешь. А если нужно обновить списки связки, то туши свет, кто во что горазд. В итоге, либо всё сохраняешь, либо используешь методы, которые обновляют заданные поля в БД.
Или повышает. Сделать хороший агрегат - сложно. Найти разрабов, которые всё не переломают - сложно. А главное: часто не нужно. Т.е. DDD - это не вершина программирования, а ещё один инструмент в арсенале.
Точно то же самое реализуется без DDD на хендлерах или юскейсах (какой-то обработчик какой-то команды). Делаем часть работы, кидаем событие или команду в outbox, где-то произойдёт дальнейшая обработка. Получаем свою "согласованность в конечном итоге" и все связанные с этим проблемы и преимущества.
Что будет внутри обработчика вообще без разницы: DDD агрегаты, вызов хранимки или призыв Ктулху.
Принципиально другим подходом я бы назвал использование оркестратора: комунды или темпорала. Но опять таки, у нас оркестрация вместо хереографии, а по факту дёргаются обработчики, которые внутри могут быть как угодно написаны.
Я со всем согласен. Просто не понимаю, зачем усложнять себе жизнь при работе в одной БД на ровном месте. На интеграции с другими сервисами хватит развлечений :)
Если декомпозиция сделано хоть как-нибудь правильно, то нам удобно в своём сервисе работать в транзакции, а с остальными сервисами "интегрироваться". Под интеграцию закладывается отдельное время разработки, т.к. вообще хз что может вылезти. А потом ещё и тестить тяжко и стрелять может долго.
Интеграция всегда дороже, чем "сохранить всё в одной транзакции". Поэтому нужно понимать, что мы получаем в замен, когда начинаем в стиле "интеграции" внутри одного приложения.
Для большинства моих задач для интеграции с другими сервисами мне хватает TransactionOutbox, позволяя надёжно выполнить изменения в другой системе после фиксации в моей (положить сообщение в очередь, дёрнуть внешний метод и т.п.).
Как с жптишкой пообщался
Да всяко можно. Как не делай, будут свои проблемы.
Осталось понять, что делать, когда в рекорде появляются массив, списки или словари. В C# по прежнему всё грустно со структурным сравнением :(
Например, чтобы уложить данные для чтения специальным образом. Или, чтобы отделить нагрузку. Или, чтобы не долбать мастер систему, а иметь копию данных у себя.
Использую рефлексию в стиле "опровергни написанное". Просто нейронка защищает свой выхлоп, нужно заставить относится к нему как к внешним данным.
Он молодец. Но мой посыл был в том, что модели рационализируют. Т.е. объяснят тебе что угодно, что лежит в контексте. Додумает и соврёт.
Иногда я прошу опровергнуть ей же написанное. Работает лучше, чем поискать ошибки.
То-то же, сказали суровые сибирские мужики
Пришлось явно запрещать расчёт, но говорит, что посчитал в уме используя распределительный закон умножения. Мне кажется, он привирает
Тогда городим. Выбора нет: либо распределённая транзакция, либо согласованность в конечном итоге.
Джун, просто каждый день новый :) Зато быстро читает и даже что-то понимает.
А в чём проблема? На аутбокс событие есть подписчик, который дёргает юскейс.
А как сделан подписчик не так уж важно: может напрямую из БД читает, может через очередь из дибезиума получает.
Меня больше волнует вопрос: зачем городить хореографию, если это всё всё одна бизнес-операция в рамках одной БД и можно просто обработать в транзакции.
Спасибо за ответ, про такое решение не подумал
Вот с этого угарнул.
Попросите модель умножить 123456 * 43223, потом попросить объяснить как она это посчитала. Она будет выдумывать, потому что она не знает, как она это сделала. Проще говоря - врать.
Для нейронки её же ответы - это внешние данные из контекста, она вообще за них не отвечает. Тем более, что контекст можно положить что угодно.
Не верите?
TL;DR: LLM - продвинутый кодогенератор
Так, я не понял, кому верить?
https://habr.com/ru/news/1015062/#comment_29725500
Нужно будет защититься, чтобы кто угодно не мог собрать что угодно. Я бы не хотел валидироваться при каждой сборке объекта из БД.
Как собрать - я понял, а как сохранять без ченж трекинга? Я вижу 2 варианта: сохранять всё или знать снаружи, что нам нужно сохранить. Может знаешь как проще?
Я просто довольно долго работал с даппером (мой пр в даппер) и сохранение было больным местом. Нужно знать что сохраняешь. А если нужно обновить списки связки, то туши свет, кто во что горазд. В итоге, либо всё сохраняешь, либо используешь методы, которые обновляют заданные поля в БД.
Или повышает. Сделать хороший агрегат - сложно. Найти разрабов, которые всё не переломают - сложно. А главное: часто не нужно. Т.е. DDD - это не вершина программирования, а ещё один инструмент в арсенале.
Даже подкаст писал на эту тему.
Соглы, архитектура важна Я успешно делаю модульные монолиты и выношу модули в отдельные сервисы по необходимости, когда понятно, что пора.
Точно то же самое реализуется без DDD на хендлерах или юскейсах (какой-то обработчик какой-то команды). Делаем часть работы, кидаем событие или команду в outbox, где-то произойдёт дальнейшая обработка. Получаем свою "согласованность в конечном итоге" и все связанные с этим проблемы и преимущества.
Что будет внутри обработчика вообще без разницы: DDD агрегаты, вызов хранимки или призыв Ктулху.
Принципиально другим подходом я бы назвал использование оркестратора: комунды или темпорала. Но опять таки, у нас оркестрация вместо хереографии, а по факту дёргаются обработчики, которые внутри могут быть как угодно написаны.
Я со всем согласен. Просто не понимаю, зачем усложнять себе жизнь при работе в одной БД на ровном месте. На интеграции с другими сервисами хватит развлечений :)
Если декомпозиция сделано хоть как-нибудь правильно, то нам удобно в своём сервисе работать в транзакции, а с остальными сервисами "интегрироваться". Под интеграцию закладывается отдельное время разработки, т.к. вообще хз что может вылезти. А потом ещё и тестить тяжко и стрелять может долго.
Интеграция всегда дороже, чем "сохранить всё в одной транзакции". Поэтому нужно понимать, что мы получаем в замен, когда начинаем в стиле "интеграции" внутри одного приложения.
Для большинства моих задач для интеграции с другими сервисами мне хватает TransactionOutbox, позволяя надёжно выполнить изменения в другой системе после фиксации в моей (положить сообщение в очередь, дёрнуть внешний метод и т.п.).
Это я понимаю.
Из-за этого мы и не пользуемся преимуществами реляционных БД. Фактически создаём себе ограничения, а потом героически их преодолеваем :D
Особенно смешно, когда кроме одной БД на проекте ничего и нет :)