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