# Принципы проектирования

Обязательные принципы для всех языков: DDD + SOLID + DRY + KISS + Clean Architecture.
Главное: архитектура помогает развитию продукта (а не усложняет ради “красоты”).

## DDD

Правила:
- Ясные bounded contexts; не смешивать термины/модели разных доменов.
- Ubiquitous language: доменные термины в коде и API.
- Домен первичен; БД/очереди/HTTP — детали.
- Доменная логика и доменные модели не зависят от SQL/HTTP/gRPC; транспортные DTO (proto/OpenAPI) маппятся на границе; границы контекстов проходят по API/событиям (не shared DB/shared tables).

## SOLID

### SRP
- Один модуль/пакет = одна ответственность; сервис = один доменный контекст.

### OCP
- Новое поведение — расширением, а не переписыванием; абстракции только при реальной вариативности.

### LSP
- Реализации строго соблюдают контракт (семантика/ошибки/ограничения).

### ISP
- Интерфейсы узкие и потребитель-ориентированные; лучше несколько маленьких, чем один “толстый”.

### DIP
- Бизнес-логика зависит от абстракций; инфраструктура реализует и подключается в composition root.

## DRY
Правила:
- Один источник правды для повторяющейся логики.
- Общий код — в `libs/`; общие транспортные контракты (gRPC) — в `proto/` (не копипаст по сервисам).
- Сигналы нарушения: одинаковые middlewares/клиенты/логгеры в каждом сервисе; копипаст SQL/DTO/валидаций; “почти одинаковые” proto для одной сущности.

## KISS

Правила:
- Простые и очевидные решения; избегать over-engineering.
- Абстракции вводить только если они уменьшают сложность.
- Transport тонкий; домен без “магии”; инфраструктура — единый способ подключения/конфигурации.

## Runtime configuration

Правила:
- Product/runtime switches, которые должны меняться на лету или аудититься как platform state, живут в typed platform settings catalog и хранятся в БД.
- Для таких переключателей обязательно фиксировать reload semantics, visibility и source-of-truth; env-only feature gates для product behavior не добавляются.
- Env остаётся только для bootstrap, secrets и infrastructure/runtime параметров, которые нужны до доступа к БД или не должны редактироваться через staff UI.

## Clean Architecture

Правила слоёв:
- Зависимости направлены внутрь: `transport -> application -> domain`; инфраструктура снаружи.
- Домен не импортирует фреймворки транспорта, драйверы БД/ORM, клиентов очередей, конкретные SDK.
- Domain задаёт интерфейсы (порты); infrastructure реализует (адаптеры); composition root склеивает.
- Критерий: бизнес-логику можно тестировать/запускать без реальных БД/очередей (через подмены интерфейсов).

## Время и часовые пояса

Правила:
- Backend: `TZ=UTC`; все временные метки в логах — UTC.
- БД: хранить время только с таймзоной (Postgres: `TIMESTAMPTZ`).
- Транспорт/API: timestamps передавать с таймзоной (RFC3339).
- Frontend: не “догадываться” про таймзону; использовать значения с tz и форматировать для пользователя в UI осознанно.
