Проект защиты

Проект защиты — изолированное приложение в предметной области геологии, которое стажёр строит с первого дня Фазы 1 и защищает на гейте в конце мес. 5/6. Это не упражнение и не курсовая — это реальный мини-продукт, нарастающий по мере освоения стека команды DeepGeo.

Принципы

Изолированный репозиторий. Проект живёт в отдельном git-репозитории стажёра. Доступа к основному коду продукта нет до защиты.
Обучение через строительство. Каждая веха M1–M4 добавляет к проекту новый слой. Теория осваивается в объёме, необходимом для текущей задачи.
Реальная предметная область. Проект работает с агрегатами из домена DeepGeo, а не с абстрактным «магазином» или «блогом». Сверка корректности полей — с домен-экспертом.
Командный стек. Технологии — те же, что в src/GeotimLab.*/GeotimLab.*.csproj. Никаких упрощений «для учебности» сверх необходимого.

Предметная область

Проект работает с цепочкой реальных агрегатов из домена инженерной геологии:

Project → Borehole → Sample → Sample_Lab → ParameterValue

Агрегат	Что представляет	Пример
`Project`	Инженерно-геологический проект	«Изыскания под здание по адресу X»
`Borehole`	Горная выработка (скважина)	«Скв-1», глубина 15.0 м, координаты
`Sample`	Образец грунта	«Образец-001», интервал 2.5–2.8 м
`Sample_Lab`	Лабораторный образец с результатами испытаний	Лабораторный шифр, дата испытания
`ParameterValue`	Значение параметра	Влажность = 12.5%, плотность = 1.98 г/см³

DDD-конвенция: только FK, без навигационных свойств

Связи между агрегатами описываются только внешними ключами. Навигационные свойства между агрегатами запрещены — это сознательная конвенция команды DeepGeo, и она соблюдается в проекте защиты с M1.

Например, Sample ссылается на выработку через поле BoreholeId (внешний ключ), но не через свойство-объект Borehole Borehole. Это правило касается связей между агрегатами — внутри одного агрегата навигация допустима.

Сверка корректности полей каждого агрегата — с домен-экспертом. Стажёр не выдумывает структуру, а уточняет её по реальной предметке. Конкретный состав и типы полей доменных классов — самостоятельное решение в рамках M1, на основе Swagger-ответов стенда и консультаций с домен-экспертом.

Архитектура проекта

Проект строится по Clean Architecture. Слои нарастают по вехам:

GeoLabDefense/
├── src/
│   ├── Domain/              # M1: агрегаты Project, Borehole, Sample, Sample_Lab, ParameterValue
│   ├── Application/         # M1: парсер (CSV/JSON → домен), M3: валидация, маппинг
│   ├── Infrastructure/      # M2: EF Core + PostgreSQL, миграции
│   └── Web/                 # M3: Web API, M4: Blazor UI
├── tests/
│   └── GeoLabDefense.UnitTests/   # xUnit, с M1
└── docs/
    └── defense.md           # документ к защите: архитектура, demo-сценарий

Направление зависимостей — строго внутрь: Web → Application → Domain. Domain не зависит ни от кого. Это проверяется на code review защиты.

Что должно быть готово к защите

Минимальные критерии готовности (детально — в чек-листе):

Функциональность: загрузка лабораторных данных из CSV/JSON → сохранение в PostgreSQL → REST/OData API → Blazor UI для просмотра.
Код: Clean Architecture, DDD-конвенции (только FK), читаемые классы, обработка ошибок.
Тесты: unit-тесты на парсер и ключевые операции (xUnit).
Инженерная зрелость: git-гигиена (осмысленные коммиты, ветки под задачи), README с инструкцией запуска, docs/defense.md.
Понимание: стажёр объясняет направление зависимостей, обосновывает выбор конвенций, отвечает на вопросы по своему коду.

Эволюция проекта по вехам

Веха	Состояние проекта
После M0	Пустой репозиторий, окружение настроено
После M1	Парсер читает CSV/JSON, создаёт доменные объекты, есть unit-тесты
После M2	Данные сохраняются в PostgreSQL через EF Core, есть миграции
После M3	REST/OData API для чтения и записи данных, валидация, маппинг в DTO
После M4	Blazor UI поверх API, готово демо и `docs/defense.md`

Сопровождение наставником

Еженедельная контрольная точка (~30 минут):.onput ревью прогресса, ответы на вопросы, корректировка направления.
Code review ключевых коммитов по запросу стажёра или при затыках.
На гейте наставник даёт материалы для оценки тимлиду, но финальное решение — за тимлидом.

Что НЕ входит в проект защиты

Чтобы удержать скоуп в 6 месяцев:

Авторизация и аутентификация (все эндпоинты открытые).
Мультитенантность (один тенант).
Файловое хранилище (S3/MinIO) — данные только в БД.
Сложные расчёты из боевого DeepGeo (LABM/LABP/LABS) — только хранение ParameterValue, без их вычисления.
Интеграция с внешними сервисами.
CI/CD и контейнеризация.

Эти темы — материал для Фазы 2, после получения доступа к основному репозиторию.

Дальше

⬅️ Обзор roadmap — дорожная карта M0–M4
➡️ QA-трек — параллельный поток работы с багами
➡️ M0 — старт — первая веха, с чего начать practically
✅ Чек-листы — критерии прохождения вех и гейта