d
Каждое поколение должно его переизобрести?)
Size: a a a
2019 December 12
PD
Ilya Galakhov
Я тут как раз для того, чтобы понять как это лучше делать сейчас, спасибо 🙂
Ну и все это поверх распределенной kv СУБД (просто она была, можно и постгресс взять). И с нотификациями по изменениям.
Там главное - это версионирование метадаты - ты по логам любой операции должен мочь понять, какая версия использовалась
И, например, завершать длинные операции с той же версией, что и начал.
Там главное - это версионирование метадаты - ты по логам любой операции должен мочь понять, какая версия использовалась
И, например, завершать длинные операции с той же версией, что и начал.
GK
Ну и все это поверх распределенной kv СУБД (просто она была, можно и постгресс взять). И с нотификациями по изменениям.
Там главное - это версионирование метадаты - ты по логам любой операции должен мочь понять, какая версия использовалась
И, например, завершать длинные операции с той же версией, что и начал.
Там главное - это версионирование метадаты - ты по логам любой операции должен мочь понять, какая версия использовалась
И, например, завершать длинные операции с той же версией, что и начал.
Вот это точно. Самая сложная задача - версионирование моделей и данных. Потому что Объект А может иметь как версию модели, так и версию данных. Точнее он всегда имеет эти версии.
И ещё многие забывают об ограничениях (constraints), а не стоит.
И ещё многие забывают об ограничениях (constraints), а не стоит.
GK
Очень надеюсь, но тучи сгущаются. Боюсь прилетит какая-нибудь встреча:(
GK
Я не такой свободный, к сожалению. Можем отдельно встретиться за мой счёт.
PD
Вот это точно. Самая сложная задача - версионирование моделей и данных. Потому что Объект А может иметь как версию модели, так и версию данных. Точнее он всегда имеет эти версии.
И ещё многие забывают об ограничениях (constraints), а не стоит.
И ещё многие забывают об ограничениях (constraints), а не стоит.
Не только объект, но и процесс )
AW
Вижу вы начинаете строить key-value-attribute схему бд. Это антипаттерн. У вас база не нормализована, потом выборки не сможете делать и расширяемость будет страдать. Плюс исходный код начнет завязываться из-за бизнес требований на содержимое колонок типа вашей data, что ведёт к утечке контроля
В этой таблице будет 1-2 тысячи строк как максимум. Выборки по data не нужны, но если сильно приспичит (не приспичит) - современные базы прекрасно работают с json полями (с такими смешными цифрами разницы в производительности не будет вообще, подозреваю).
AW
Ну и в итоге ничего кроме монолита не получится построить, то есть теряете в гибкости дальнейшего развития. Или может каждому микросервисы свой key-value-attribute конструктор типов сделать? Или может сделать это отдельным микросервисом?) В общем губите гибкость
Я не понимаю, как это приводит к монолиту. Я наоборот отделил некую систему, включая ее хранилище. Сама по себе система никак не завязана на этих самый данных, она лишь знает что там лежит null или json. Остальное - задача клиентского кода (и.е. того, который уже связан с бизнес логикой).
AW
Если "система" как то и зависит от бизнес логики, то только через интерфейсы и без жесткой связанности.
IN
Если "система" как то и зависит от бизнес логики, то только через интерфейсы и без жесткой связанности.
Ошибаешься на уровне функционала. Вьетнам не пройдёшь, Гена прав. Учи матчасть. Извини за резкость
AW
Ошибаешься на уровне функционала. Вьетнам не пройдёшь, Гена прав. Учи матчасть. Извини за резкость
"Учи матчасть" - слишком абстрактный совет.
IN
"Учи матчасть" - слишком абстрактный совет.
Короче, тогда твоя задача подходит для select * from everything
GK
Не только объект, но и процесс )
Версионирование это ещё не всё ). Мы мозг заставляли работать, когда моделировали представление иерархий в разных разрезах (с разных точек зрения). Например, один и то же продукт может иметь разные представления в разрезе орг. структуры и в разрезе продуктовой линейки. Иными словами в Туле и в Москве продукт может отличаться,
PD
А, ну это в DDD просто в разных доменах по разному представляется )
IN
А, ну это в DDD просто в разных доменах по разному представляется )
Не совсем
GK
Не совсем
Да, не всё так просто)
PD
Или синхронизация через сообщения )
GK
Не могу к сожалению поддержать разговор прямо сейчас
IN
Или синхронизация через сообщения )
Например, а это уже функция предметной области