вот для такого приложения предложи вариант "потери консистентности"

кроме багов в твоем коде

еще раз, у васи нужно отнять 5, у пети прибавить 5

$transactions->add()

а потом по доменным ивентам строим балансы васи и пети

изи бризи

или даже веселее

в inmemory есть транзакции?

там не нужны транзакции

у тебя однопоточное приложение, гонок быть не может, все строго последовательно

все операции со стэйтом атомарны

сча погодь

пример нарисую

я тебя понял

я не понял почему ты частный случай стораджа, который в общем и не сторадж вовсе, выставляешь эталоном, тогда как все внешние стораджи оказываются исключениями с костылями вида flush :)

class Account { public function deposit(int $amount, Account $sender) { $sender->decreseAmount($amount); $this->increaseAmount($amount); $this->transactions->add(new Transaction($sender, $this, $amount)); } private function decreseAmount(int $amount) { if ($this->balance < $amount) { throw new UnsuficientBalance($this->id, $this->balance, $amount); } $this->balance -= $amount; } }

я не понял почему ты частный случай стораджа, который в общем и не сторадж вовсе, выставляешь эталоном, тогда как все внешние стораджи оказываются исключениями с костылями вида flush :)

"все внешние которые реляционные"

почему реляционные? любые

ты можешь взят документноориентированную базу и хранить каждый агргегат сущностей как JSON

поскольку ты каждый раз трогаешь только один агрегат - операция по итогу атомарна

но flush надо будет всеравно дернуть что бы затригерить синхронизацию

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

но последнее ооочен сложно и слишком волшебно

бизнес транзакция != транзакция в базе

короч да, flush нужен для любой модели хранения где нужна синхронизация

ага, но как правило очень близко

ага, но как правило очень близко

это не является поводом их отождествлять

синхронизация нужна всегда

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

можно ли так же с репозиторием после add?

можно ли так же с репозиторием после add?

add очень редко является концом бизнес транзакции

просто в случае inmemory синхронизация настолько копеечная, что не выделена отдельно

и add может работать не над сущностью, а над набором правил, ничего не мешает

просто в случае inmemory синхронизация настолько копеечная, что не выделена отдельно

где ты там синхронизацию увидал? у тебя объекты просто в памяти лежат, нечего синкать.

где ты там синхронизацию увидал? у тебя объекты просто в памяти лежат, нечего синкать.

а это уже реализация

просто представь себе что репозиторий для любого стораджа это immemory + sync

соответсвенно для inmemory репозитория sync не нужен

inmemory все же не uow?

sync это тот самый кастыль который позволяет тебе работать с хралилищем как с inmemory репозиторием.

uow - это как раз таки sync в случае с доктринами и прочими

а inmemory репозиторий - это просто хранить ссылку на объект

считай identity map

да, вот identity map это вполне себе часть inmemory repository так как нам нельзя допустить "клонов" сущностей

add очень редко является концом бизнес транзакции

наверное, я не понимаю, что такое бизнес-транзакция

хотя.... я чет не могу придумать как там могут быть клоны... так что хз

наверное, я не понимаю, что такое бизнес-транзакция

бизнес-транзакция = бизнес-операция = юзкейс

> группа логически объединённых последовательных операций по работе с данными, обрабатываемая или отменяемая целиком.

тут нужно тебе определиться, или inmemory - это не сторадж, тогда сравнивать со стораджем и говорить - а тут flush костыль - не верно. Или inmemory считаем стораджем, но тогда имеем скрытый flush - т.е. то, что по ->add ну нас сразу объект попадет в inmemory сторадж - и есть flush

если ты добавишь слово "бизнес" - это это группа бизнес операций например)

ну регистрация пользователя - бизнес транзакция, и users->add() является её концом?

или прочие вещи, которые должны происходить при регистрации - тоже часть бизнес транзакции?

тут нужно тебе определиться, или inmemory - это не сторадж, тогда сравнивать со стораджем и говорить - а тут flush костыль - не верно. Или inmemory считаем стораджем, но тогда имеем скрытый flush - т.е. то, что по ->add ну нас сразу объект попадет в inmemory сторадж - и есть flush

я повторюсь, представь что у тебя бесконечное количество памяти и тебе не нужны отдельные стораджи

это идеализированная модель

ага, и еще у тебя только один поток

ну один поток это потому что я не знаю умеешь ли ты в lock-free структуры, семафоры и прочее

это не модель, это, извини, крайний случай

это не модель, это, извини, крайний случай

"модель" и есть крайний случай)

нет, потому что если у тебя два потока - тебе нужны транзакции, пусть путем блокировок, но flush - нужен

нет, потому что если у тебя два потока - тебе нужны транзакции, пусть путем блокировок, но flush - нужен

нет, flush всеравно не нужен

у тебя в памяти лежит объект, и ты просто доступ к стэйту закрываешь семафорами и юзаешь lock-free коллекции к примеру

ты можешь это "транзакциями" называть если хочешь конечно, но это не те самые транзакции

два объекта

два объекта - нет необходимости в рарзграничении

один объект - две операции паралельные - тут надо семафоры или чего-нибудь такое

не, смотри, ты изменил первый объект, но ты не можешь с него снять блокировку

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

не, смотри, ты изменил первый объект, но ты не можешь с него снять блокировку

это называется "баг в твоей реализации"

ты работал с локами вообще?

ERROR: S client not available

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

если кто-то уже получил доступ к стэйту - метод будет ждать пока освободится занятый стэйт

короч, в любом случае это все не важно

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

+5 -5

я тебе выше пример скинул как это происходит

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

как раз таки что бы небыло необходимости заморачиваться

короч, модель идеальной системы хранения которая описывает идею persistance ignorance - однопоточное приложение без необходимости локов (что бы не усложять реализацию), которая хранит весь стэйт в памяти и никогда не падает.

если ты можешь себе представить такую реализацию (не заморачиваясь о ее не применимости в реальном мире) - то ты можешь себе предтавить основную идею за unif of work и т.д

ага, выбросили из машины колеса, двигатель и руль и рассказываем на этом примере о идельном странспорте ;)

ага, выбросили из машины колеса, двигатель и руль и рассказываем на этом примере о идельном странспорте ;)

почитай определение слова "модель"

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

что бы не тратить время на объяснение концептов которые тебе на данном этапе не нужны

точно так же - если я хочу объяснить тебе идею persistance ignorance - самый простой вариант это однопоточное приложение выполняющая все операции последовательно и хранящая весь свой стэйт в памяти процесса.

почитай определение "адекватность модели" ;)

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

идея в том что бы бизнес логика и бизнес операции были максимально изолированы от инфраструктуры и максимально близко соответствовали идее "думай что стэйт у тебя просто лежит в памяти"

и тогда эту бизнес логику можно будет "читать" бизнесу

а реализация uow - она storage-specific?

вслух

а реализация uow - она storage-specific?

как сделаешь так и сделаешь. В Doctrine она универсальна и потому дико медленная. Это тупой derty-checker

у тебя был стэйт, у тебя есть стэйт, diff -> генерим запросы

ну то есть как "универсальная" - для одног осимейства хранилищ

скажем для тех же коменентноориентированных своя реализация UoW

хоть и очень похожая

документноориентированных*

отлично, т.е. получаем один интерфейс uow для всех, разные реализации, одна из которых вполне может содержать flush

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

отлично, т.е. получаем один интерфейс uow для всех, разные реализации, одна из которых вполне может содержать flush

все будут содержать flush

flush/sync/syncronize

ну все, пофиг, ты вспомни о чем речь с самого начала шла