2. Unique constraint в PostgreSQL и есть idempotency key. RabbitMQ без persistence, дополнительная точка отказа. Нагрузка, осознанный трейдофф, PgBouncer и партиционирование в бэклоге.
3. Храним в ETH, провайдер присылает сконвертированное. NUMERIC(38,18), worst case для любого ERC-20 с 18 decimals.
5. REPEATABLE READ, NOWAIT, lock_timeout, statement_timeout, catch на LockNotAvailable, QueryCanceled, DeadlockDetected, всё в коде.
CHECK constraint есть, balance_non_negative CHECK (balance >= 0) прямо в схеме в статье.
Осознанный выбор в пользу PostgreSQL как единственного источника правды. Unique constraint даёт атомарность которую Saga с RabbitMQ без persistence не даст.
именно про это написан отдельный раздел. NUMERIC(38,18) везде, _validate_amount явно отклоняет float с сообщением "float не допускается".
Представления и pg_cron, вкусовщина, не антипаттерн.
Уровни изоляции, REPEATABLE READ в balance check, NOWAIT на всех блокировках, lock_timeout, явный catch на DeadlockDetected.
Спагетти-код, не понял к чему это.
Такое ощущение, что вы комментировали не читая статью.
Хороший программист именно поэтому и открывает EXPLAIN ANALYZE, чтобы не гадать. 280k строк, seq scan, 28 секунд, это не угадаешь по коду. Угадывание в продакшне стоит дорого.
легаси без индексов годами, это не баг, а рынок. Кто не встречал, тому повезло. ORM и Django проекты живут по своим законам, это немного другой мир)) По поводу похожей статьи, жду ссылку. Пока звучит как легенда.
А как цифра 87% гарантирует или хотя бы показывает, что критичные пути покрыты?
Согласен, 87% это метрика дисциплины, не качества. Реальная защита была бы через покрытие конкретных use case: GetBranchReport, расчёт выручки, агрегация остатков. Цифра просто не даёт скатиться ниже порога.
Вообще-то, есть куча подходов, где бизнес-логика выделена в отдельный слой/модуль. То есть, это не уникальное свойство DDD и не в DDD это придумали.
Не претендовал на уникальность DDD в этом вопросе. Clean Architecture решает то же самое. Выбор был прагматичный, так как команда знала DDD, переходить на другой подход было дороже, чем результат.
А как цифра 87% гарантирует или хотя бы показывает, что критичные пути покрыты?
Согласен, 87% это метрика дисциплины, не качества. Реальная защита была бы через покрытие конкретных use case: GetBranchReport, расчёт выручки, агрегация остатков. Цифра просто не даёт скатиться ниже порога.
Вообще-то, есть куча подходов, где бизнес-логика выделена в отдельный слой/модуль. То есть, это не уникальное свойство DDD и не в DDD это придумали.
Не претендовал на уникальность DDD в этом вопросе. Clean Architecture решает то же самое. Выбор был прагматичный, так как команда знала DDD, переходить на другой подход было дороже, чем результат.
У нас домен был скромнее: Order, Branch с базовыми правилами валидации. Use Case оркестрирует, Repository абстрагирует. Намеренно не стал грузить статью полным примером, там своя история на отдельный пост)) 10 kloc на один MR, уважаю. Скрытая логика умеет прятаться!
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
2. Unique constraint в PostgreSQL и есть idempotency key. RabbitMQ без persistence, дополнительная точка отказа. Нагрузка, осознанный трейдофф, PgBouncer и партиционирование в бэклоге.
3. Храним в ETH, провайдер присылает сконвертированное. NUMERIC(38,18), worst case для любого ERC-20 с 18 decimals.
5. REPEATABLE READ, NOWAIT, lock_timeout, statement_timeout, catch на LockNotAvailable, QueryCanceled, DeadlockDetected, всё в коде.
разберём по пунктам:
CHECK constraint есть, balance_non_negative CHECK (balance >= 0) прямо в схеме в статье.
Осознанный выбор в пользу PostgreSQL как единственного источника правды. Unique constraint даёт атомарность которую Saga с RabbitMQ без persistence не даст.
именно про это написан отдельный раздел. NUMERIC(38,18) везде, _validate_amount явно отклоняет float с сообщением "float не допускается".
Представления и pg_cron, вкусовщина, не антипаттерн.
Уровни изоляции, REPEATABLE READ в balance check, NOWAIT на всех блокировках, lock_timeout, явный catch на DeadlockDetected.
Спагетти-код, не понял к чему это.
Такое ощущение, что вы комментировали не читая статью.
Хороший программист именно поэтому и открывает EXPLAIN ANALYZE, чтобы не гадать. 280k строк, seq scan, 28 секунд, это не угадаешь по коду. Угадывание в продакшне стоит дорого.
Без ссылки - несерьёзно. Минусуйте на здоровье, Django переживёт)
легаси без индексов годами, это не баг, а рынок. Кто не встречал, тому повезло. ORM и Django проекты живут по своим законам, это немного другой мир)) По поводу похожей статьи, жду ссылку. Пока звучит как легенда.
Согласен, 87% это метрика дисциплины, не качества. Реальная защита была бы через покрытие конкретных use case: GetBranchReport, расчёт выручки, агрегация остатков. Цифра просто не даёт скатиться ниже порога.
Не претендовал на уникальность DDD в этом вопросе. Clean Architecture решает то же самое. Выбор был прагматичный, так как команда знала DDD, переходить на другой подход было дороже, чем результат.
Согласен, 87% это метрика дисциплины, не качества. Реальная защита была бы через покрытие конкретных use case: GetBranchReport, расчёт выручки, агрегация остатков. Цифра просто не даёт скатиться ниже порога.
Не претендовал на уникальность DDD в этом вопросе. Clean Architecture решает то же самое. Выбор был прагматичный, так как команда знала DDD, переходить на другой подход было дороже, чем результат.
У нас домен был скромнее: Order, Branch с базовыми правилами валидации. Use Case оркестрирует, Repository абстрагирует. Намеренно не стал грузить статью полным примером, там своя история на отдельный пост)) 10 kloc на один MR, уважаю. Скрытая логика умеет прятаться!