Вот вам конкретно про консистентность при покупке товара, который заканчивается
"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, на уровне платформы.
Я думаю лучше брать какие-то примеры по сбору и анализу метрик, например. Не лезть в бизнес и тем более корпоративные решения.
Простой gps-трэкер тоже хороший пример. Накидываем координаты - лог, видим маршрут на карте - вью. А если бы мы просто фиксировали текущие координаты, то маршрут не отследить.
В биллинг системе мы просто фиксируем факт звонка и длительность. А потом мы все это складываем и получаем счет.
Без обид, но штат 25 человек и пример одного кандидата ... Это как случайно споткнуться и выдать исследование о высоте плинтусов. Искренне надеюсь, что самому Вам понравилось и было интересно.
Табличка с заказом это на самом деле 3 таблички. 1 таблица - id заказа и данные о заказчике. 2 таблица - состояния заказов, 3 табличка - содержимое заказа. При оплате заказа, создается задание на отгрузку, которое отражается также тремя таблицами, аналогично. Далее запросом можно уже получать количество и содержимое заказов, оплаты по ним и отгрузки.
Считаем сколько мы заплатили за это программисту, закрываем бизнес пока не дошло до продажи почки.
Кому нужна надежность в оплате и отгрузке заказов, те купят 1С. Ну или битрикс. Ну другое готовое решение. В здравом уме никто не закажет разработку такого.
Пытаться найти что-то новое в платежах и заказах это прекрасно как любое изобретение велосипеда. Найти бы дураков, которые за такое платят.
Если опыт работы соответствует резюме, то скорее всего никаких сюрпризов не будет. В среднем, на прежнем месте работы, у человека был такой же наниматель, как и вы. Это больше про техническую часть, конечно. Специалист по персоналу может сказать как человек поведет себя в коллективе, конфликтен ли, есть лидерские качества и все такое. Но это совсем другое образование и другая специальность, далекая от технарей. И я таких вообще пока не особо видел =)
А вы что делаете, когда товар на складе закончился, что сообщаете юзеру? Просто "иди на хер"?
Вот вам конкретно про консистентность при покупке товара, который заканчивается
"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)
Это готовое решение, готовая платформа. Как ни крути. Притом концептуально это именно ES, на уровне платформы.
Я думаю лучше брать какие-то примеры по сбору и анализу метрик, например. Не лезть в бизнес и тем более корпоративные решения.
Простой gps-трэкер тоже хороший пример. Накидываем координаты - лог, видим маршрут на карте - вью. А если бы мы просто фиксировали текущие координаты, то маршрут не отследить.
В биллинг системе мы просто фиксируем факт звонка и длительность. А потом мы все это складываем и получаем счет.
И главный вопрос возникает - а кто делает иначе?
Про возраст понятнее не стало =)
Без обид, но штат 25 человек и пример одного кандидата ... Это как случайно споткнуться и выдать исследование о высоте плинтусов. Искренне надеюсь, что самому Вам понравилось и было интересно.
Табличка с заказом это на самом деле 3 таблички. 1 таблица - id заказа и данные о заказчике. 2 таблица - состояния заказов, 3 табличка - содержимое заказа. При оплате заказа, создается задание на отгрузку, которое отражается также тремя таблицами, аналогично. Далее запросом можно уже получать количество и содержимое заказов, оплаты по ним и отгрузки.
Считаем сколько мы заплатили за это программисту, закрываем бизнес пока не дошло до продажи почки.
Кому нужна надежность в оплате и отгрузке заказов, те купят 1С. Ну или битрикс. Ну другое готовое решение.
В здравом уме никто не закажет разработку такого.
Пытаться найти что-то новое в платежах и заказах это прекрасно как любое изобретение велосипеда. Найти бы дураков, которые за такое платят.
Я исхожу из нормального хода событий, при котором на резюме без важных Х вы не отвечаете.
Все сделанное, сначала придумано. Это неизбежный процесс. Ни секунды не потеряете, если сначала придумаете.
А в чем проблема продумать до конца?
Если опыт работы соответствует резюме, то скорее всего никаких сюрпризов не будет. В среднем, на прежнем месте работы, у человека был такой же наниматель, как и вы. Это больше про техническую часть, конечно. Специалист по персоналу может сказать как человек поведет себя в коллективе, конфликтен ли, есть лидерские качества и все такое. Но это совсем другое образование и другая специальность, далекая от технарей. И я таких вообще пока не особо видел =)