Size: a a a

Software Design/Architecture/Zen

2021 June 05

DP

Dimitry Polonskiy in Software Design/Architecture/Zen
Еще вопросец возник:
Верно ли определение:
"Агрегат это граница согласованности, которая говорит нам, что можно изменить атомарно, а что нет"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
это несколько другой вопрос.

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

Как "раньше" было - есть скажем бизнес аналитик. Он 3+ месяцев вкуривает в предметную область, разбирается "че зачем и почему". Составляет спецификацию, описывает юзкейсы и вот это все. Имея доступ к разработчикам может придумывать решения. Такая вот прослойка для формализации требований. И не нужны никакие эти ваши DDD.

Что изменилось за последние 20-30 лет - это степень интеграции IT в бизнес. Если раньше речь шла о прямом переносе бизнес процессов то сегодня IT системы сильно влияют и трансформируют бизнес сам по себе. Изменился характер взаимодействия с клиентами бизнеса. Изменились требования к скорости поставки - все очевидное сделано - нужно экспериментировать - нужно сокращать риски для экспериментов.

Раньше у тебя небыло выбора и ты покупал мэйнфрейм, сегодня ты можешь в клаудах деплоиться и за счет этого существенно сокращать расходы на operations. Раньше "можно было раз в месяц патчить сервера и все было ок", сегодня слишком много вещей которые отъедают времени и сил и потому появляются решения типа serverless и прочие идеи platform as a service.

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

SP

Sergey Protko in Software Design/Architecture/Zen
граница транзакции по сути. Кусочек стэйта системы для которого нам необходимо immediate consistency.
источник

DP

Dimitry Polonskiy in Software Design/Architecture/Zen
Да, но просто не очень люблю употреблять слово транзакция, отдает базами.
Граница бизнес процесса может?
источник

DP

Dimitry Polonskiy in Software Design/Architecture/Zen
Хотя может мне кажется  :(
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Ну это твоя проблема что они у тебя отдают базами данных, но "граница консистентности" хоть и подходит под описание важно понимать разницу между eventual и immediate consistency.

бизнес процесс может состоять из нескольких логических транзакций.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
транзакционность просто хорошо описывает все вот эти "атомарность консистентность"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
основной смысл - есть стэйт системы. Всей. Если хочешь что бы стэйт системы был консистентным и за этим следит приложение (например стэйт ты в файликах хранишь) то у тебя все операции над стэйтом системы должны быть последовательны. То есть один чел делает - остальные ждут.

Это "работает" когда у тебя пользователей системы мало, чем больше пользователей системы тем больше необходимость данные партицировать. Каждый такой партишен все еще требует последовательной работы но поскольку партишенов много - общая пропускная способность системы увеличивается.

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

DP

Dimitry Polonskiy in Software Design/Architecture/Zen
"но стэйт всей системы в отдельные моменты времени может не быть консистеным (у одного деньги списал а второму еще не начислил)."
Вот тут уже Eventual нужен
Ведь так?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
да. Только важно понимать что eventual consistency это достаточно сложно. Если есть возможность этого всего избежать - лучше избегать. Даже в сложных бизнес системах необходимость в этом всем существует в относительно небольшом количестве мест. А большая часть вещей тупо круды.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
В целом эти вот вопросы - агрегаты, консистентность, партиципование - это все не имеет к DDD отношения, просто про распределённый стэйт, масштабирование и т.д.

DDD в этом всем может только помочь с моделированием.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Потому так удобна реляционная модель - оч много вопросов консистентность стэйта можно просто на нее скинуть
источник

DP

Dimitry Polonskiy in Software Design/Architecture/Zen
Благодарю за разьянесние!
источник

AN

Allan Nettzan in Software Design/Architecture/Zen
Это про первичные и внешние ключи?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
это про ссылочную целостность, есть еще просто констрейтны, нет проблем "менять несколько вещей в одной транзакции" и т.д.
источник

ST

Serguei Tarassov in Software Design/Architecture/Zen
Не сколько сама модель (она продуманная) , сколько реализующие модель промышленные СУБД, поддерживающие ограничения целостности и транзакции.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
тут больше в контексте "надо две штуки поменять - если что-то пошло не так все откатится мне не надо ни за чем следить и ничего продумывать, никаких этих ваших компенсационных действий и прочего"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну и "предметная область че? у продукта есть описание и цена, и так сойдет"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
нормальные формы на примере классов и учеников осилили и хватит.
источник

K

Konstantin in Software Design/Architecture/Zen
Помню как у нас самый популярный интернет магаз ит продуктов и компонентов, когда случилось с 3000х серией, просто все покупали кто зашёл в процедуру чекаута в таймфрейм, а они потом отменяли каждому покупателю заказы в ручную. 😁

Сидишь такой, купил, деньги списали, а через несколько дней сообщение в личку от кастомер сервис «сорян у нас нет»
источник