Вы мне пальцем покажите, где вы читаете про то, что в рамках ES чего-то нельзя. На данный момент получается, что вы придумали свой плохой ES и его обсуждаете.
Конкретно блокируется запись событий для этого счета.
В 1С остатки и обороты всегда сумма событий. Там конечно еще куча остального есть, которое не ES.
Чтобы понимать экономию на облаках, надо понимать сколько компания вообще тратит штат программистов, разрабатывающих более эффективное решение. Т.е. вот сэкономили дискового пространства на 30 000 рублей, программистам заплатили 3 000 000 рублей, хороший бизнес ... у программистов.
Так же как и не в ES поменять состояние объектов. Заблокировать на время транзакции. Вопросы странные. Как так можно ездить на велосипеде, упадешь же, а на машине фыр-фыр и едешь. Бывает так, что не нужна информация о конечном остатке на строго текущий момент всегда, а нужна по запросу и на любой момент времени.
Т.е. теоретически никто не мешает хоть сейчас повесить триггер и обновлять где-то остаток на сейчас. Просто не всегда требуется. Ну будет на экране плясать цифра, толку от нее. Она несколько раз в секунду может меняться.
ES это не технология искажения состояния, гарантии не ухода в минус такие же, как везде. Работа с финансами происходит транзакциями, сумма которых складывается в состояние счета, тут даже думать не надо о паттерне.
А что касается товаров. В реальности имеем "Сбермаркет", который может и на этапе сборки накосячить и на этапе доставки. При их оборотах, отсутствие товара это норма. Просто предлагают замену или уменьшают сумму. А один раз реально забыли из машины достать, а я в этой куче пакетов тоже не могу полную инвентаризацию делать.
Сейчас блокируется не весь лог, а только по конкретным товарам и складам. Актуальный достаток доступен на любой момент времени.
Ну и интеграция, куда без нее. В бухгалтерию данные как попадут? А еще системы доставки, лояльности, поддержки клиента. Чего вам толку то от актуального остатка на неизвестно еще какой момент.
Вы какой-то свой ES придумываете, который будет удобно обличать. Официальный документ гласит "At any point, it's possible for applications to read the history of events. You can then use it to materialize the current state of an entity by playing back and consuming all the events that are related to that entity. This process can occur on demand to materialize a domain object when handling a request. Or, the process occurs through a scheduled task so that the state of the entity can be stored as a materialized view, to support the presentation layer."
Вот вам конкретно про консистентность при покупке товара, который заканчивается
"It is worth bearing in mind that an application may not actually require data to be consistent all of the time. For example, in a typical ecommerce web application that enables a user to browse and purchase goods ..." и далее по ссылке
Договор публичной оферты. Работает когда товар выставлен непосредственно на полке и вы пришли с ним на кассу.
Но Вы же сами говорите, что наличие остатка в программе (а именно это и есть, "числится") не имеет отношения к архитектуре программы. Тогда о чем в сущности разговор?
Нет никакого пересчета регистров. Остатки и обороты - виртуальные таблицы, формируемые в момент запроса. Не существует физически таблиц с остатками. Промежуточные итоги есть, на начало каждого месяца. И только.
Контроль остатков осуществляется 2мя способами. В бухгалтерии до выполнения движений получаются остатки и проверяется, что они не уйдут в минус. В торговле сначала делаются движения, потом анализируются остатки и если они отрицательные, то транзакция откатывается. При том такая проверка в торговле происходит и при попытке распровести поступление, например.
Провел - в таблицу записали строку +1 Распровел - из таблицы убрали запись.
Нет никакой строгой консистентности в реальной жизни. Вы чет себе придумали, чего в реальности никогда не будет, потому что человеческий фактор. Вы никогда не можете быть уверены, что человек правильно ввел данные для изменения состояния.
Просто пример. На кассе человек выкладывает товар, а у вас он не числится (не успели, проморгали, разное). Вы не продадите товар, потому что в минус уйдете? Ну удачи вам с таким бизнесом.
Деньги испокон века на ES, с первых бухгалтерских книг. В основе работы с деньгами транзакции и аудит. Как производить аудит операций, если их не записывать? Мол вот написано 100 рублей на счете и всё, компутер так видит.
В ES резервирование такое же событие. Оно и в реальности должно быть перемещением с общей полки, в специальную зону, где товар собирается и помечается для отгрузки по определенному счету. Пришел товар, в логах +1, переместили товар, в логах -1 +1, отгрузили товар, в логах -1. В сумме имеем состояние.
Все верно. В этом суть ES, когда процесс записи данных и расчета результата происходят отдельно.
Самый понятный объект - премия. Вы можете организовать процесс так, чтобы премия всегда была одной цифрой напротив вашей фамилии и доступна в любой момент времени? Это ведь очень удобно, можно выдать ее в любой момент.
То же со скидками.
И главное, никогда не ставится под сомнение весь результат. Можно проанализировать весь лог событий, скорректировать отдельные позиции и получить правильный результат. А если вы произвели 1000 операций, не запоминая их, то сомнительный результат идет в корзину. Невозможно разрешить конфликт о достоверности результата.
И самое главное (ага, в конце) - соотношение между входящей информацией и исходящей. Объект имеющий одно конечное состояние заблокирован всегда. И это здорово объединяет оба подхода. Всегда надо знать сколько именно сейчас денег на балансе или товара на складе. Это момент, который блокирует и все транзакции его изменяющие - блокирующие. Но в ES не будут заблокированы данные до сего момента. Все, что в прошлом, все транзакции, которые подтверждены, уже - признано достоверным - может быть исправлено В отличии от систем, которые хранят только конечно состояние.
И теперь самый подходящий момент, чтобы спросить. А что такое настоящая консистентность? Для меня настоящий - реальный, реализуемый в реальной жизни, в текущей реальности. Насколько я понимаю, сейчас это решается просто абонентской платой, которая походит на взнос по страховке. Все заплатили по 300 рублей, но все наговорили разные минуты. Это консистентность?
Вы мне пальцем покажите, где вы читаете про то, что в рамках ES чего-то нельзя. На данный момент получается, что вы придумали свой плохой ES и его обсуждаете.
Конкретно блокируется запись событий для этого счета.
В 1С остатки и обороты всегда сумма событий. Там конечно еще куча остального есть, которое не ES.
Чтобы понимать экономию на облаках, надо понимать сколько компания вообще тратит штат программистов, разрабатывающих более эффективное решение. Т.е. вот сэкономили дискового пространства на 30 000 рублей, программистам заплатили 3 000 000 рублей, хороший бизнес ... у программистов.
Так же как и не в ES поменять состояние объектов. Заблокировать на время транзакции. Вопросы странные. Как так можно ездить на велосипеде, упадешь же, а на машине фыр-фыр и едешь.
Бывает так, что не нужна информация о конечном остатке на строго текущий момент всегда, а нужна по запросу и на любой момент времени.
Т.е. теоретически никто не мешает хоть сейчас повесить триггер и обновлять где-то остаток на сейчас. Просто не всегда требуется. Ну будет на экране плясать цифра, толку от нее. Она несколько раз в секунду может меняться.
Меня тут осенило. Когда хотят сделать редактор с функцией отмены, то там фиксируется лог действий пользователя. Вот это прикольный кейс.
Пример SWT Undo Redo : Undo Redo « SWT JFace Eclipse « Java (java2s.com)
MS вот считают, что для ecom это здорово. 1С каноничная ES.
Ну и событийная интеграция.
Реализация взаимодействия между микрослужбами на основе событий (события интеграции) | Microsoft Learn
ES это не технология искажения состояния, гарантии не ухода в минус такие же, как везде. Работа с финансами происходит транзакциями, сумма которых складывается в состояние счета, тут даже думать не надо о паттерне.
А что касается товаров. В реальности имеем "Сбермаркет", который может и на этапе сборки накосячить и на этапе доставки. При их оборотах, отсутствие товара это норма. Просто предлагают замену или уменьшают сумму. А один раз реально забыли из машины достать, а я в этой куче пакетов тоже не могу полную инвентаризацию делать.
Сейчас блокируется не весь лог, а только по конкретным товарам и складам. Актуальный достаток доступен на любой момент времени.
Ну и интеграция, куда без нее. В бухгалтерию данные как попадут? А еще системы доставки, лояльности, поддержки клиента. Чего вам толку то от актуального остатка на неизвестно еще какой момент.
Вы какой-то свой ES придумываете, который будет удобно обличать. Официальный документ гласит
"At any point, it's possible for applications to read the history of events. You can then use it to materialize the current state of an entity by playing back and consuming all the events that are related to that entity. This process can occur on demand to materialize a domain object when handling a request. Or, the process occurs through a scheduled task so that the state of the entity can be stored as a materialized view, to support the presentation layer."
Event Sourcing pattern - Azure Architecture Center | Microsoft Learn
А вы что делаете, когда товар на складе закончился, что сообщаете юзеру? Просто "иди на хер"?
Вот вам конкретно про консистентность при покупке товара, который заканчивается
"It is worth bearing in mind that an application may not actually require data to be consistent all of the time. For example, in a typical ecommerce web application that enables a user to browse and purchase goods ..." и далее по ссылке
Data Consistency Primer | Microsoft Learn
Договор публичной оферты. Работает когда товар выставлен непосредственно на полке и вы пришли с ним на кассу.
Но Вы же сами говорите, что наличие остатка в программе (а именно это и есть, "числится") не имеет отношения к архитектуре программы. Тогда о чем в сущности разговор?
Нет никакого пересчета регистров. Остатки и обороты - виртуальные таблицы, формируемые в момент запроса. Не существует физически таблиц с остатками. Промежуточные итоги есть, на начало каждого месяца. И только.
Контроль остатков осуществляется 2мя способами. В бухгалтерии до выполнения движений получаются остатки и проверяется, что они не уйдут в минус. В торговле сначала делаются движения, потом анализируются остатки и если они отрицательные, то транзакция откатывается. При том такая проверка в торговле происходит и при попытке распровести поступление, например.
Провел - в таблицу записали строку +1
Распровел - из таблицы убрали запись.
Так что я ничего не путаю
Вся страна ведет бухгалтерию и торговлю в продуктах на основе ES. Такова реальность, нет смысла ее отрицать.
Продублирую еще раз
Event Sourcing pattern - Azure Architecture Center | Microsoft Learn
Нет никакой строгой консистентности в реальной жизни. Вы чет себе придумали, чего в реальности никогда не будет, потому что человеческий фактор. Вы никогда не можете быть уверены, что человек правильно ввел данные для изменения состояния.
Просто пример. На кассе человек выкладывает товар, а у вас он не числится (не успели, проморгали, разное). Вы не продадите товар, потому что в минус уйдете? Ну удачи вам с таким бизнесом.
Нет никакого обновления суммы. Она вычисляется каждый раз.
Event Sourcing pattern - Azure Architecture Center | Microsoft Learn
Деньги испокон века на ES, с первых бухгалтерских книг. В основе работы с деньгами транзакции и аудит. Как производить аудит операций, если их не записывать? Мол вот написано 100 рублей на счете и всё, компутер так видит.
В ES резервирование такое же событие. Оно и в реальности должно быть перемещением с общей полки, в специальную зону, где товар собирается и помечается для отгрузки по определенному счету. Пришел товар, в логах +1, переместили товар, в логах -1 +1, отгрузили товар, в логах -1. В сумме имеем состояние.
А как это делать в другой методологии?
Если совсем по ES, то оформляется факт физического выбытия товара с полки и тут невозможно ошибиться. Иначе вы должны блокировать изменения.
Все верно. В этом суть ES, когда процесс записи данных и расчета результата происходят отдельно.
Самый понятный объект - премия. Вы можете организовать процесс так, чтобы премия всегда была одной цифрой напротив вашей фамилии и доступна в любой момент времени? Это ведь очень удобно, можно выдать ее в любой момент.
То же со скидками.
И главное, никогда не ставится под сомнение весь результат. Можно проанализировать весь лог событий, скорректировать отдельные позиции и получить правильный результат. А если вы произвели 1000 операций, не запоминая их, то сомнительный результат идет в корзину. Невозможно разрешить конфликт о достоверности результата.
И самое главное (ага, в конце) - соотношение между входящей информацией и исходящей. Объект имеющий одно конечное состояние заблокирован всегда. И это здорово объединяет оба подхода. Всегда надо знать сколько именно сейчас денег на балансе или товара на складе. Это момент, который блокирует и все транзакции его изменяющие - блокирующие. Но в ES не будут заблокированы данные до сего момента. Все, что в прошлом, все транзакции, которые подтверждены, уже
- признано достоверным
- может быть исправлено
В отличии от систем, которые хранят только конечно состояние.
И теперь самый подходящий момент, чтобы спросить. А что такое настоящая консистентность? Для меня настоящий - реальный, реализуемый в реальной жизни, в текущей реальности. Насколько я понимаю, сейчас это решается просто абонентской платой, которая походит на взнос по страховке. Все заплатили по 300 рублей, но все наговорили разные минуты. Это консистентность?
Вот примерно такие статьи тут ждут Списки (synset.com)