Size: a a a

Software Design/Architecture/Zen

2021 May 24

AN

Allan Nettzan in Software Design/Architecture/Zen
Добрый вечер.
Заметил такую странность

Некоторые именно в рсубд базу сохраняют не уид а наименование агрегата или сущности + уид

Для нереляционок это выглядит адекватно.
Но зачем в рсубд?
источник

AN

Allan Nettzan in Software Design/Architecture/Zen
Тип ключ стринговый.
Какой профит?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
профит - юзать одну табличку для разных агрегатов. По сути для агрегатов нужен простой key-value стор как правило.
источник

AN

Allan Nettzan in Software Design/Architecture/Zen
Так самое смешное что  хранится снапшот
источник

AN

Allan Nettzan in Software Design/Architecture/Zen
Не события
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну какая разница, тоже тупой key-value
источник

SP

Sergey Protko in Software Design/Architecture/Zen
какой смысл дробить это на таблицы если у тебя выборки всеравно будут тип + айдишка
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Айдишник, тип, стейт
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
норм же
источник

AN

Allan Nettzan in Software Design/Architecture/Zen
Order table:
Id
Date
ClientId
ClosedDate
Вот в такой таблице тип норм?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну это не похоже на то что ты описываешь. Так что "хз"
источник

IS

I Scarab in Software Design/Architecture/Zen
Коллеги, подскажите, в правильную ли сторону я думаю.
Условно, есть некий проект (предположим, интернет-магазин). Проект связывается с большим числом внешних систем (например 1С, процессинг, таможенная система и так далее). Связь где-то односторонняя, где-то двусторонняя (реализованы могут быть и push и pull, а могут и не быть).
Для ряда сущностей есть следующие операции:
1. Запросить (pull) внешние данные (например, информацию о заказе в 1С).
2. Получить (push) уведомление из внешней системы об изменении (например менеджер изменил заказ в 1С) или что-то прилетело через кафку.
3. Отправить (push) уведомление во внешнюю систему об изменении сущностей (клиент отменил заказ).
Что-то из этого нужно кэшировать, чтобы не нагружать постоянно запросами внешние ресурсы.

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

Вопрос: а если из внешней системы получаем только очень маленький кусок данных (например, только дату растаможки из таможенной системы) - корректно ли делать для этой мелкой сущности отдельный репозиторий?

Или лучше вообще как-то по-другому делать?
источник

IS

I Scarab in Software Design/Architecture/Zen
И туда же: а как лучше делать, если часть информации хранится в локальной БД, а часть - тянется из внешних систем?
Например заказ в интернет-магазине весь лежит внутри, а дата растаможки тянется извне?
Репозиторий в репозиторий?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
не надо называть это репозиторием и жизнь станет проще
источник

SP

Sergey Protko in Software Design/Architecture/Zen
назови gateway
источник

NT

Nikita Tolkachev in Software Design/Architecture/Zen
Со стороны перфа разве то же самое будет?
источник

IS

I Scarab in Software Design/Architecture/Zen
А кроме названия, есть существенные различия?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
зависит от СУБД. Все это влияет на размеры индекса, а это в свою очередь на перорманс. Если даже начнет прижимать сильно - можно сделать партишенинг.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну просто если ты не будешь думать о внешних системах как о "хранилищах" то может быть в голове чуть упростится схема.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
не стоит пытаться "найти один паттерн что бы рулить ими всеми".
источник