Project Platform
Цільова архітектура повної міграції зі старих stack-golden, stack-prime, stack-chathouse і проєктних модулів Stack у спільну платформу. Однакові frontend/business flows реалізуються один раз у project-application-api, а partner API та справді унікальні правила залишаються у відповідному проєктному сервісі project-*.
Перший production vertical slice — Golden. Legacy Golden та старий Electron продовжують обслуговувати ще не перенесені capability, але вже перенесена capability має canonical collection, одного writer-а і окремий rollback flag.
Порядок проєктування
Розділи
| Розділ | Що там | ✅ | 🟡 | ⬜ | Разом |
|---|---|---|---|---|---|
| Entities | Структура спільних collections, проєктні поля та правила доступу | 0 | 16 | 0 | 16 |
| Universal Services | Спільні модулі, frontend API та flow, написані один раз | 0 | 20 | 0 | 20 |
| Project Services | Операції, які потрібно реалізувати в кожному проєктному сервісі | 0 | 11 | 0 | 11 |
| Workers | Фонова синхронізація даних у кожному проєкті | 0 | 6 | 0 | 6 |
| Разом | 0 | 53 | 0 | 53 |
Файли кореня
| № | Файл | Що описує |
|---|---|---|
| 01 | Platform Boundaries | Поділ packages, Stack, Platform API, Gateway, Electron і нових проєктних сервісів. |
| 02 | Multi-repo Development | Окремі Git repositories, локальні links, private packages, Electron CI та project-platform. |
| 03 | Golden Migration | Паралельний запуск legacy/V2, shadow, test Electron, pilot, feature flags і rollback. |
| 04 | New Project Checklist | Що обов’язково реалізувати при підключенні нового партнерського сайту. |
Поділ логіки
Папка одразу показує, скільки роботи виникне для нового проєкту. Однаковий опис у кожному модулі не повторюємо.
| Де | Як реалізується |
|---|---|
services/ | Пишеться один раз і працює для всіх проєктів. |
project/ | Контракт спільний, реалізація partner API дописується для кожного проєкту. |
Project-only у проєктному файлі | Унікальна логіка конкретного проєкту, яку треба написати окремо. |