Всем привет! Пишу сейчас приложение аля учета финансов и возникли вопросы.

Просто не знаю как лучше сделать

Предыстория
При добавлении/редактировании/удалении транзакции, мне нужно обновлять баланс аккаунта привязанного к транзакции
Я сейчас делаю это в сервисе, но мне постоянно кажется что это не то место, ибо постоянно в конце каждой логики нужно не забыть дописать updateBalance еще и передать правильные данные
Я подумываю о том чтоб перенести эту логику в хуки afterCreate, afterUpdate и тд, в модели. Почему-то додумался загуглить их существование ток недавно 😬

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

Например, есть у тебя коллекция todo. И есть бизнес правило, не больше 10 в коллекции. Есть юзкейс на добавление новой записи в коллекцию. Чтобы соблюсти бизнес правило “не больше 10 на коллекцию” тебе надо, чтобы в момент выполнения юзкейса, количество тудушек не менялось пока ты не завершишь свой юзкейс (свою бизнес транзакцию). Это и есть транзакционная консистентность бизнес правил. Теперь пример с событийной консистентностью. Условия те же самые, есть коллекция todo и правило не больше 10. Ты дёргаешь юзкейс на добавление новой записи в коллекцию, но уже не гарантируешь того, что в момент создания записи будет соблюдено правило 10-ти. После создания записи - создаётся ивент, который уже и повлечет за собой проверку на правило 10 (сага), и если это правило будет нарушено, то будут произведены компенсирующие действия. По аналогии с агрегатами из стратегического DDD, я бы внутри сервиса (агрегата) обеспечивал транзакционную консистентность бизнес правил, а между сервисами – событийную. *один нюанс. Бизнес транзакция понятие шире, чем транзакция в бд. Бизнес транзакция подразумевает еще и лок

Честно, как фронтендер, я вроде все понял, но не уверен. Т.е. я понимаю надобность это делать, но не понимаю каким образом мне это делать и как проверить не сделано ли это уже в моей системе Я так понимаю что чтоб понять как это обеспечивать, мне придется изрядно погуглить?

Если что, систему пишу я сам и это пет проект, потому под «проверить что это уже сделано» подразумевается «как понять что я случайно это уже не обеспечил»

> Я так понимаю что чтоб понять как это обеспечивать, мне придется изрядно погуглить? Вообще, вся теоретическая база по поводу консистентности бизнес правил, которую я описал, есть в книжках по DDD (у Эванса, Вернона). Наугглить прям готовый ответ на стаковерфлов не получится скорее всего, а тем более относительно подхода с жирными сервисами.

Много кто пихает логику в сервисы, много кто не знает про Rich Domain Model и всем окей что бизнес правила не соблюдаются. Если это один из первых проектов на беке, то пиши как получится, а потом почитай Эванса, Вернона, Хорикова и перепиши нормально

Но даже в контекте «как получится», выносить логику обновления балансов в хуки модели не лучшее решение, верно? Лучше оставить в сервисах и покрыть юнит-тестами? Я так понимаю в хуках лучше всего как-то форматировать/валидировать данные, но не более

Под Active Record можно подразумевать что модель содержит методы для CRUD данных самой модели? Если так, то да. И да, это sequelize

Acrive Record это когда объект строка из таблички. Который сам себя умеет обновлять, как правило

>выносить логику обновления балансов в хуки модели не лучшее решение, верно? Ну главное не размазывать бизнес логику по всем слоям. Если выбрал сервисы, то держи её в сервисах. А в хуки можно класть любую другую логику

Что ж, в принципе, логично 🙂 Спасибо за много инфы!