SP
если мы говорим про юзкейсы где это важно (резервация мест в кинотеатре) то там у тебя в любом случае чуть другие механизмы.
Size: a a a
2020 December 15
SP
тут другое - если у тебя есть "заказ" разных статусов с разными данными - какие-то данные не привязаны к статусу заказа и "перекидывать" их не надо.
SP
или вот еще - ты хочешь искать "когда оформляли заказ или когда его подтвердили или когда доставили" - три таблички - три выборки. простой union айдишек и потом уже детали по айдишкам
SP
есть масса способов работать со стэйтом. ЛОгический кохижен "все что связано с заказом ложим в orders" это "ок" для монолитов и для систем где нет особой колаборации и гонок (то есть 90% всех продуктов)
SP
поскольку это ок для 90% продуктов для остальных 10-ти которые могли бы выйграть обычно ты тоже этот способ видишь - он привычный и не требует больших усилий в плане моделирования данных
SP
если у тебя есть статусы но нет колаборации я бы в целом не парился особо. Грубо говоря если у тебя есть пост в инсте и ты его делаешь драфтом, а потом публикуешь и гонок быть не может - то нет смысла париться
SP
колаборация есть когда два человека чет делает - менеджер подтверждает заказ когда покупатель его отменяет, такого рода вещи
ЕР
Сейчас меня волнуют скорее if-ы появляющиеся от того что статусы переменной заданы
SP
у меня вот есть под рукой сущность где ~10 статусов со сложными правилами переходов и вот там разбиение на оч маленькие агрегаты оч сильно упрощает код
ЕР
Но разбивать в уже существующем(легаси) коде всё-равно не просто
SP
сделали действие - создали штуку. Хотим сделать действие а сущность "не в том статусе" - нет записи в базе - ты идешь нафиг
SP
Но разбивать в уже существующем(легаси) коде всё-равно не просто
не просто, тут добавить нечего)
SP
я потому на эту сущность с 10-ю статусами смотрю уже 2 года...
ЕР
И ещё надо чтоб это хотя бы агрегатом стало самодостаточным, то есть без связей через орм всего и вся
SP
И ещё надо чтоб это хотя бы агрегатом стало самодостаточным, то есть без связей через орм всего и вся
а для этого нужны инструменты как решить те проблемы которые ты до этого этими связями решал. Например мне пришлось реализовать application side джойны для этого
SP
что бы связи для UI перенести на уровень UI из бизнес лэйера
SP
ну и еще надо хорошо понимать флоу пользователя что бы не попасть в ситуацию с кривыми моделями данных - это тоже сложно часто - нет под рукой людей которые могут с этим помочь
SP
не зная флоу можно придумать кучу фич которые твои красивые агрегаты превратят в кашу за счет никому не нужных фич
SP
были у меня как-то задачки в плане "хотим поиск по всему просто так". Работало это убого и проблема была в том что никто не знал как ищут.
ЕР
были у меня как-то задачки в плане "хотим поиск по всему просто так". Работало это убого и проблема была в том что никто не знал как ищут.
Чёт напоминает то что наши фронты хотят jsonapi