особенно когда post который ты там передаешь имутабельный

Однако в первом случае насколько я понял наш пост имммутабелен, а в случае с классом - стейт класса мутируется .

Есть принципиальная разница в этом?

Есть же вот это из мира реакта, "что иммутабельность круто"

а если бы это был VO? 🙂

Тогда все есть - VO?)

Не понимаю зачем это. Если есть инвариант, то его надо проверять где-то. Хоть в окнструкторе, хоть в функции.

Наверное это надо выности в прекондишн, ну или вообще не делать такое условие обязательным, а просто добавить в post.setTitle автоматическую генерацию слага для удобства

представь что у системы есть инвариант что "слаг уникален". где ты будешь это форсить?)

Уникальный индекс в бд 🙃

инварианты они у стэйта, нет стэйта нет инвариантов 😉

только прекондишены и пост кондишены

Спасибо, задача проектирования решена)

ты знаешь в чем проблема у goto? почему оно considered harmful?

Да на уровне сервиса в транзакции делать проверку. Я вообще тут спрашивал уже подобный вопрос. Посоветовали обеспечивать eventual consistency и откатывать неуникальный агрегат назад после завершения транзакции по его добавлению или делать констрейнты на уровне бд. Если честно не понял зачем это, если можно все в одной транзакции сделать

Теряем нормальный control/execution flow, что то в этом роде, не могу по научному сформулировать

там смысл в том что мозги у нас не оч любят симулировать процессы разворачивающиеся во времени. Это для них оч сложно. То есть условно...

x = y + 4

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

В этом плане имутабельность это последовательный дата флоу, то есть ты знаешь что на вход пришло и знаешь что выйдет на выход. За этим очень легко следить.

если у тебя за целостность по итогу база отвечает то нахер тебе вся эта канитель с инвариантами? И как транзакции тебе чего гарантируют без лока таблицы? а лок таблицы разве не говорит что вся коллекция постов это один жирнющий агрегат?

eventual consistency позволяет не делать локов. в этом как бы задумка

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

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

системный АНАЛитик? впервые слышу. про бизнес-аналитиков слышал - в чём разница? И если разница есть, то чем системный аналитик от архитектора отличается?