зависимости на которую предметная область не должна завязываться.
Объекты Date/DateTime это еще и внепроцессная зависимость или только волатильная зависимоcть?
Какой практический смысл изолировать предметную область от Date/DateTime?
Мне кажется если для ui, то как раз расходится. Типа как может в ui попасть то, что не было создано в ходе бизнес транзакции. А если чисто для аудита, то нет. Ну наверное
ну прост ты говоришь, что эти createdAt не связаны с логикой никак. Если так - зачем плодить всякие "предметные области", это ж просто CRUD.
Ну почему. Дата созданич сущности. Чтобы потом показывать на фронте
Ну это он и говорит. Но мой вопрос в том насколько эта независимость от дейта нужна?
иногда имеет смысл, тут уже говорили про платежи видел доклад Солнцева (автор Селенида), что ловили хейзенбаг тесты, которые иногда падали, а на время критичный функционал завязан... конкретный случай был связан с тем, что убунта при апдейте версии обновила поставщика времени и как-то хитро переключалась решением было: использовать не системное время, а относительнео время в Джаве
Как минимум тестить это функцию будет просто, снижение когнитивный нагрузки всей кодовой базы. Представьте у вас 80% кодовой базы это чистые функции. Если дата время там реально нужны можно просто передать clock
время штука сложная, если ты можешь спроектировать систему так что бы она не полагалась на "текущее время" а скорее на таймстэмпы которые приходят снаружи у тебя будет куда больше возможностей по тестируемости и гибкости системы. Есть много разных идей вокруг этой темы. В целом рекомендую почитать чего на тему functional core imperative shell
ааа, да есть в моем выражении такие проблемы, по сути вы получается что система существует, по ее snapshot в runtime, а не в runtime по ее uptime. Вот этот разрыв между snapshot и uptime и есть глубина ямы. В некоторых системах он ближе к единице (отношение слепка-snapshot отчета от запаздывания наполнения и все отлично, напримерd системах управленческого учета). А вот в "живых" типа систем обработки транзакций сделок 24/7 или систем производства он отличен от единицы, то есть меньшее ее, и начинаются я проблемы в оценке, и чем ближе к нулю, тем больше проблем.
Это вы так описали ГЭП в eventual consistency?
вопрос же только в требованиях к времени выполнения? Ну то есть останавливать время же всё равно придётся
проблемы ли это. ну то есть.... то что стэйт системы может не быть консистентным в конкретный момент времени не есть проблема сама по себе.
мне очень нравится пример Альберто Брандолини из его книжки про event storming. мол у него там был пример на тему того что бизнес по своей природе строится на доверии и на eventual consistency. идешь ты такой по парку и захотел покушать. Стоит лоток с хотдогами. Ты такой подходишь к нему и просишь мол "дай ка мне хотдог", а он такой "5 баксов". Ты даешь ему деньги и ждешь. И пока ты ждешь он вполне может сбежать с твоими 5-ю баксами и не будет хотдога. И в целом операцию обмена такую никак не выйдет сделать атомарно. Невозможно за одну операцию сьесть хотдог и обменяться деньгами.
но можно прописать концепт в котором мы можем доверять потребителю, а не просто его заявлении о получении не получении, потреблении не потреблении. кстати именно это пытались продать в блокчейне, но потом оказалось что не всем это нужно, и доверие не совсем полное.
Обсуждают сегодня