Rustam Khalimov
27c7831910
ci / build-test (push) Canceled after 0s
SaaS-мониторинг Telegram: ядро (модули Cards/Kanban/Pipeline/Tenants/Settings/ Discovery, Api, Infrastructure), сервисы telegram/ai/ml/storage, фронт Vue, контракты и grpc-hosting, деплой-конфиги (dev/prod/observability/CI-раннер), Gitea Actions CI, документация (ТЗ, техдок, api-map, код-стайл, планы, бэклог). Текущее состояние: все этапы роадмапа 0–12 закрыты, сборка 5 sln 0/0, тесты 1340/130/52/38/9 зелёные.
54 lines
3.8 KiB
Markdown
54 lines
3.8 KiB
Markdown
# Дизайн: разбиение проектов на логические папки (namespace = папка)
|
|
|
|
Дата: 2026-09-11. Статус: согласовано владельцем (решения 1–5).
|
|
|
|
## 1. Цель
|
|
|
|
Упорядочить код по назначению: вместо «свалки» файлов разных видов в одной папке с единым
|
|
`namespace` — подпапки по назначению, при этом `namespace` соответствует пути папки.
|
|
|
|
## 2. Таксономия папок (по назначению)
|
|
|
|
| Папка | Что кладём |
|
|
| --- | --- |
|
|
| `Abstractions/` | интерфейсы `I*.cs` |
|
|
| `Services/` | прикладная логика: `*Service`, `*WorkerService.*`, `*Guard`, `*Pacer`, `*Evaluator`, `*Counter`, `*Detector`, `*Normalizer`, `*Matcher`, `*Composer`, `*Cleaner`, `*Classifier`, `*Mapper`, `*Builder`, `*Writer`, `*Recomputer`, `*Suggester`, `*Filler`, `*Generator`, `*Hasher` и аналогичные исполнители |
|
|
| `Models/` | доменные типы: сущности, value-объекты, enum, статусы/виды, константные реестры (`*Statuses`, `*Kinds`, `*Prefixes`, `*Keys`, `*Events`, `*Periods`, `*Sources`, `*Field`, `*Defaults`) |
|
|
| `Dtos/` | транспортные типы: `*Dto`, `*Request`, `*Response`, `*Patch` |
|
|
| `Extensions/` | `*Extensions` |
|
|
| `Options/` | `*Options` |
|
|
| `Exceptions/` | `*Exception` |
|
|
| `Registrars/` | `*ModuleRegistrar` |
|
|
|
|
Существующие feature-папки (`ColumnRules`, `Parse`, существующие `Models`) сохраняются.
|
|
|
|
## 3. Правила
|
|
|
|
1. `namespace` строго соответствует пути папки.
|
|
2. Имена типов и публичные контракты не меняются — только расположение и `namespace`.
|
|
3. Один тип = один файл (уже соблюдается).
|
|
4. Частичные классы (`Foo.cs`, `Foo.Part.cs`) переносятся вместе.
|
|
5. Тестовые проекты группируются по областям: `Modules/<X>`, `Api`, `Infrastructure` и т.п.,
|
|
`namespace` = `Deal.Tests.Unit.<Область>`.
|
|
|
|
## 4. Механика переноса (на проект)
|
|
|
|
1. Классифицировать файлы по таблице §2.
|
|
2. Перенести файлы в подпапки и заменить `namespace`.
|
|
3. Миграция `using`: в файлах-потребителях заменить несуществующий старый `using <OldNs>;` на
|
|
`using` всех новых подпространств (пере-добавление безопасно; при коллизии имён — ручное разрешение).
|
|
Файлы внутри проекта-источника получают `using` соседних подпространств.
|
|
4. `dotnet build` → исправить остатки (полные имена, `cref`), `dotnet test`.
|
|
5. Отдельный коммит (русский) после каждого проекта.
|
|
|
|
## 5. Порядок
|
|
|
|
Пилот — `Deal.Modules.Cards` (чистый домен). Далее: остальные `Deal.Modules.*`, затем
|
|
`Deal.Infrastructure`, `Deal.Api`, `Deal.Contracts`/`Deal.SharedKernel`, сервисы `telegram/ai/ml`,
|
|
затем тестовые проекты. После каждого шага — сборка + тесты + коммит.
|
|
|
|
## 6. Риски
|
|
|
|
- Коллизия простых имён при пере-добавлении `using` → разрешается вручную по ошибкам сборки.
|
|
- Не забыть `cref`/полные имена в XML-док и `nameof` — выявляются сборкой.
|