A
Юзеры от этого не распухнут от ожирения? =)
Size: a a a
2021 May 05
ПГ
Так вопрос то был даже не про БД. Вопрос был: делать единую историю (снаружи агрегатов) или много разных на каждый агрегат (внутри каждого агрегата). А уж БД - это следствие
˸A
если БД - это следствие агрегатов - то я сдаюсь... в ФП чатах ни разу про агрегаты не упоминали, а БД там, или другая монада - им всё равно
ПГ
Короче вопрос был не про БД, я вот к чему.
˸A
У меня всё просто в коде:
А что там будет в БД - мне всё равно
export type Order<T extends Total | Shipping | Items<Item>> = T & {
invoiced: T[],
refunded: T[],
canceled: T[],
}А что там будет в БД - мне всё равно
SP
ты тож рак плодишь
˸A
рак - это новое название абстракции?)
SP
не, агрегатам тоже пофиг че там в базе. Агрегаты строятся вокруг инвариантов стэйта. Тебе как ФП-нику наоборот такое должно было бы нравиться
SP
хуевой абстракции да
˸A
конструктивненько)
SP
я утверждаю что иметь "абстракцию" под названием
Order приводит к раку (неконтролируемо растущей опухоли) в 99% случаевSP
просто потому что "слишком жирная штука". Какой-нибудь
OrderID еще нормN
Оффтоп среди ваших дисскусий: понятие "агрегат" строго имеет отношение к DDD или это более общее понятие?
SP
конкретно "агрегаты" да, из DDD пошли. Но можно тоже самое именовать "партиция данных" и тогда можно из других топиков почитать погуглить
N
˸A
OrderID у меня даже нету в либе нигде. всё в рамках одного заказа (так сказать, суперсет бизнес-модели)SP
ну и говорю я - это рак. Просто потому что такие вещи как "заказы" или там "кастомеры" - это все не мэпится на какой-то один контекст, и как следствие потом будут проблемы масштабировать систему с точки зрения разработки.
˸A
для этого придумали OCP - в этом контексте (вычисления сумм для инвойсов/рефандов/отмен) - применяется эта модель, в других контекстах - без изменения этой модели можно расширить
˸A
точно так же, как теория множеств - это частный случай теории категорий
SP
слишком быстро про ТК, толсто