Синхронний підпроект: openprocurement
Стек: Pyramid + pymongo + schematics. Основний продакшн API із повною функціональністю.
Коренева директорія: src/openprocurement/
Інфраструктурний пакет api/
Містить увесь базовий рівень, від якого успадковуються всі доменні пакети.
Файл / директорія |
Призначення |
|---|---|
|
Ініціалізація Pyramid-додатку; підключення всіх includeme |
|
|
|
Thread-local контекст запиту ( |
|
Автентифікація брокерів і сервісних токенів |
|
Бізнес-константи та константи з env-змінних ( |
|
Спільні утиліти: |
|
Декоратори валідації запитів |
|
WSGI-middleware (таймінги, логування) |
|
|
|
Базові schematics-моделі: |
|
|
|
Базові серіалізатори відповідей |
|
(порожньо на рівні api; конкретні views — в доменних пакетах) |
|
Базова інфраструктура міграцій ( |
|
Базові утиліти для тестів: |
Глобальні pytest-фікстури: src/openprocurement/conftest.py
Доменні пакети
Кожен домен — окремий пакет: tender/, contracting/, framework/, planning/, relocation/, historical/.
Всередині кожного домену:
core/— спільна логіка для всіх типів процедур доменуКонкретні типи процедур (
belowthreshold/,open/,contract/тощо)
Структура всередині кожного типу процедури:
<domain>/<type>/
├── procedure/
│ ├── models/ # schematics-моделі об'єктів (Tender, Contract, Bid тощо)
│ ├── state/ # бізнес-логіка переходів станів
│ ├── views/ # Pyramid-в'юхи (GET, POST, PATCH)
│ └── serializers/ # серіалізатори відповідей
├── migrations/ # міграції даних у MongoDB (нумеровані, 0001_…)
└── tests/ # інтеграційні тести
Правила розміщення коду
Бізнес-логіка →
procedure/state/; state-класи не роблять запити до БД напрямуЗапити до БД → лише з
procedure/views/(черезrequest.registry.mongodb.<collection>)Валідація вхідних даних →
procedure/models/(schematics) іvalidation.pyСеріалізація відповіді →
procedure/serializers/Зміна схеми / даних у БД →
migrations/(не в коді ініціалізації)Спільні утиліти домену →
<domain>/core/Глобальні константи з часовою прив’язкою →
constants_env.py(читаються з env абоconstants.ini)