# Дизайн: разбиение проектов на логические папки (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` — выявляются сборкой.