P—02 · Системный анализProduction

ТехРент

CRM для аренды спецтехники — бронирование с проверкой доступности, календарь парка, платежи, права менеджеров и журнал действий.

Код

Роль: Аналитика, проектирование, разработка в Claude Code (дипломный проект)
Период: 2026.06 → 2026.10
Статус: Production
Стек: Go · PostgreSQL · React · TypeScript · Zustand · Docker · Nginx · OpenAPI · BPMN

Интерфейс

01 / 06

Календарь занятостиДиаграмма Ганта «техника × дни» за сентябрь: заказы по статусам и период обслуживания бульдозера жёлтой полосой.

Задача

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

Решение

ТехРент заменяет таблицы простым веб-сервисом для менеджеров. Система сама проверяет, свободна ли техника на нужные даты, считает стоимость аренды по ставкам, следит за оплатой и показывает должников. Администратор приглашает менеджеров по ссылке и выдаёт им права по разделам, а каждое изменение попадает в журнал.

Дипломный проект. Готовую систему я передал на обзор компании с собственным парком техники и получил обратную связь от её руководителя. Я вёл его как аналитик и архитектор — требования, модель данных, API, ролевая модель, — а код писал в Claude Code пошагово, с проверкой каждого шага. Отдельно разобрал главную фичу, бронирование, сквозным кейсом и принял реализацию по коду — так нашлись 11 расхождений с требованиями.

Цели

01Не допустить двойного бронирования и аренды неисправной техники
02Видеть занятость всего парка на месяц за одну минуту
03Считать стоимость и долги без ручных расчётов
04Давать менеджерам ровно те права, которые им нужны

Функции

Каталог техники: ставки за день и час, статусы, фото, периоды обслуживанияКлиенты (юрлица и физлица) и их объекты-стройплощадкиБронирование с проверкой доступности и расчётом стоимостиКалендарь занятости — диаграмма Ганта «техника × дни»Платежи с частичной оплатой и защитой от переплатыФинансовая сводка за период и список должниковПриглашение менеджеров по ссылке и права по модулямЖурнал действий: кто, что и когда изменил, данные до и после

Ключевые требования

ID	Требование	Приоритет
FR-01	Одна техника не может быть занята двумя неотменёнными заказами на пересекающиеся даты — даже при одновременных запросах.	Must
FR-02	Сломанную технику забронировать нельзя (422), технику на обслуживании — в его даты (409).	Must
FR-03	Стоимость: несколько дней — ставка за день × дни включительно, один день — ставка за час × часы.	Must
FR-04	Сумма платежей по заказу не может превысить сумму заказа.	Must
FR-05	Номер заказа ТР-год-NNN уникален и не повторяется после удаления заказа.	Must
FR-06	Менеджер видит и меняет только разделы, открытые ему администратором.	Should
NFR-01	Целостность на уровне БД: CHECK, UNIQUE, внешние ключи и ограничение EXCLUDE.	Must
NFR-02	Каждое создание, изменение и удаление пишется в журнал; сбой журнала не отменяет операцию.	Must
NFR-03	Вся система поднимается одной командой docker compose up.	Should

Сценарии

МенеджерБронирование техники

01Находит свободную технику в календаре и отмечает даты
02Форма подставляет ставки и считает сумму, менеджер выбирает клиента и объект
03Сервер в одной транзакции проверяет поломку, обслуживание и занятость
04Заказ получает номер ТР-2026-015, событие попадает в журнал

АдминистраторПриглашение менеджера

01Создаёт менеджера и отмечает разделы и действия, которые ему доступны
02Получает одноразовую ссылку на 7 дней и передаёт её
03Менеджер сам задаёт пароль — администратор его не видит
04Права попадают в токен при входе, меню показывает только разрешённое

Ход работы

Шаги 1–3ОсноваDocker Compose, Go API на Chi, миграции, встроенные в бинарник, JWT и роли.
Шаги 4–7УчётКаталог техники, клиенты и объекты, заказы с расчётом стоимости, платежи.
Шаги 8–11КонтрольЖурнал действий, календарь Ганта, обслуживание техники, статусы заказов по датам.
Шаги 12–14Персонал и финансыПанели деталей, приглашения и права менеджеров, финансовая сводка и должники.
ПриёмкаКейс и обратная связьСквозной кейс «Бронирование», 11 замечаний по коду и отзыву компании; исправлены все три высоких и повтор номеров.
ДалееУведомления и документыУведомления в Telegram, договор, счёт и акт в PDF, аналитика загрузки парка.

Сложности

Двойное бронирование при одновременных запросахПроверка и запись шли отдельными запросами. Теперь — одна транзакция с блокировкой строки техники, а в БД ограничение EXCLUDE: из 10 одновременных запросов проходит один, остальные получают 409.

В форме была видна только часть техникиКомпания с 24 машинами при обзоре не нашла нужную: сервер молча обрезал список до 20. Явная ошибка 400 вместо подмены и поле выбора с серверным поиском.

Номер заказа мог повторитьсяCOUNT + 1 выдавал занятый номер после удаления заказа. Таблица-счётчик по годам: номер выдаётся в транзакции заказа, не повторяется и не оставляет пропусков.

Статус заказа зависит от сегодняшней датыВ БД хранятся только «запланирован» и «отменён», а «активен» и «завершён» вычисляются в SQL при чтении — без ночных задач и рассинхронизации.

Результат

Работающая CRM из 14 шагов — около 5,5 тысячи строк Go и 6,5 тысячи строк TypeScript, — с обратной связью от реальной компании. Сквозной кейс бронирования, OpenAPI, BPMN и словарь данных; из 11 замечаний аналитика исправлены все три высоких и повтор номеров, гонки проверены одновременными запросами.

Дальше — права на изменение и отмену заказа на сервере, уведомления в Telegram и документы в PDF.

Технологии

#Go #PostgreSQL #React #TypeScript #Zustand #Docker #Nginx #OpenAPI #BPMN

§ 2.1

Компоненты

Три контейнера в Docker Compose. Nginx раздаёт React-приложение и проксирует /api на Go-сервис. Внутри сервиса — слои handler → service → repository, связанные через интерфейсы. Бизнес-правила живут в сервисе, а инварианты, которые нельзя нарушить ни одним путём записи, держит PostgreSQL.

FIG. 02 — компоненты

X 000 · Y 000

01
WEBReact + TypeScript. Zustand хранит сессию, Axios сам обновляет токен, Гант на чистом CSS.
02
NGINXРаздаёт сборку, отдаёт index.html на любой маршрут SPA, проксирует /api и /uploads.
03
GO APIGo 1.24: handler → service → repository через интерфейсы. Миграции встроены в бинарник и запускаются при старте.
04
POSTGRESPostgreSQL 16: ограничение EXCLUDE от двойной брони, CHECK на суммы и даты, счётчик номеров.
05
UPLOADSТом Docker с фотографиями техники.
06
TELEGRAMУведомления о заказах — следующий шаг, поле для chat_id уже в схеме.

§ 2.2

Бронирование техники

Участники

01 · МЕНЕДЖЕРНайти свободную техникуКалендарь показывает заказы и обслуживание; сломанной техники в нём нет.
02 · МЕНЕДЖЕРЗаполнить заказСтавки подставляются из техники, сумма считается сама, клиент и объект — из базы.
03 · СИСТЕМАПроверить датыФормат YYYY-MM-DD и конец не раньше начала, иначе 400.
04 · СИСТЕМАПроверить доступностьСломана — 422; обслуживание или занята на эти даты — 409.
05 · СИСТЕМАСохранитьНомер ТР-год-NNN, статус «Запланирован», запись в журнал.
06 · МЕНЕДЖЕРПодтвердить клиентуСообщает номер заказа и даты; при отказе подбирает другие даты или технику.

§ 2.3

Запрос POST /orders через слои

Участники

01 · MIDDLEWAREПроверить токенПодпись и срок JWT, id, роль и права кладутся в context. Нет токена — 401.
02 · SERVICEРазобрать датыСтрого time.DateOnly до любых проверок.
03 · REPOSITORYЗаблокировать техникуBEGIN; SELECT статус и обслуживание … FOR UPDATE — запросы на одну машину встают в очередь.
04 · SERVICEПроверить доступностьПоломка, обслуживание, пересечение с неотменёнными заказами.
05 · POSTGRESНомер и записьUpsert в order_counters, INSERT … RETURNING с вычисленным статусом. EXCLUDE — последняя страховка.
06 · HANDLERОтвет и журналCOMMIT, 201 с заказом; событие CREATE в журнал, его сбой ответ не меняет.

§ 2.4

Модель данных

Заказ ссылается на клиента, объект, технику и менеджера через внешние ключи с ON DELETE SET NULL — история заказов переживает удаление справочников. Ставки копируются в заказ, поэтому смена ставок техники не меняет оформленные суммы.

USERS6 п.

iduuidPK

emailvarcharUK

roleadmin|manager

permissionsjsonb

statusactive|pending

invite_tokenvarcharUK

EQUIPMENT8 п.

iduuidPK

namevarchar

categoryvarchar

statusenum

daily_ratenumeric

hourly_ratenumeric

maintenance_fromdate

maintenance_todate

EQUIPMENT_PHOTOS4 п.

iduuidPK

equipment_iduuidFK

urlvarchar

is_primarybool

CLIENTS5 п.

iduuidPK

typelegal|individual

namevarchar

innvarchar

phonevarchar

OBJECTS5 п.

iduuidPK

client_iduuidFK

namevarchar

addresstext

is_activebool

ORDERS12 п.

iduuidPK

numbervarcharUK

equipment_iduuidFK

client_iduuidFK

object_iduuidFK

manager_iduuidFK

statusplanned|cancelled

start_datedate

end_datedate

total_amountnumeric

paid_amountnumeric

payment_statusenum

PAYMENTS5 п.

iduuidPK

order_iduuidFK

amountnumeric

methodenum

created_byuuidFK

AUDIT_LOG6 п.

idbigserialPK

user_iduuidFK

actionvarchar

entity_typevarchar

old_datajsonb

new_datajsonb

Связи · 9

EQUIPMENT— 1 : N →EQUIPMENT_PHOTOS

EQUIPMENT— 1 : N →ORDERS

CLIENTS— 1 : N →OBJECTS

CLIENTS— 1 : N →ORDERS

OBJECTS— 1 : N →ORDERS

USERS— 1 : N →ORDERS

ORDERS— 1 : N →PAYMENTS

USERS— 1 : N →PAYMENTS

USERS— 1 : N →AUDIT_LOG

§ 2.5

API и интеграции

GET/api/v1/calendar?from&toЗанятость техники за период, сгруппированная по машинам
POST/api/v1/ordersЗабронировать технику: 201, 400, 409 (занята, обслуживание), 422 (сломана)
PUT/api/v1/orders/{id}Изменить заказ; сам заказ из проверки конфликтов исключается
PATCH/api/v1/orders/{id}/statusОтменить заказ — принимается только cancelled
POST/api/v1/paymentsПринять платёж; переплата — 422 внутри той же транзакции
GET/api/v1/finance/summary?periodСводка за месяц, квартал или год и текущие долги клиентов
POST/api/v1/usersПригласить менеджера: ссылка на 7 дней и права по модулям
GET/api/v1/auditЖурнал действий с данными до и после (только администратор)

Nginx → Go APIHTTP · REST JSONNginx раздаёт сборку React и проксирует /api и /uploads на сервис.
JWTBearerAccess-токен на 1 час и refresh на 7 дней; права менеджера лежат в токене.
Telegram (планируется)Bot APIУведомления о создании и отмене заказа; поле telegram_chat_id уже есть.

§ 2.6

Ключевые решения

Решение 01

Статусы заказа вычисляются по датам

Выбор: В БД только planned и cancelled, остальное — CASE WHEN в каждом SELECT.
Обоснование: Статус всегда актуален в момент чтения, не нужна фоновая задача, которая может упасть.
Альтернативы: Хранить все статусы и обновлять их ночным заданием.

Решение 02

Блокировка строки техники плюс EXCLUDE

Выбор: SELECT … FOR UPDATE на технике в транзакции заказа и ограничение-исключение по диапазону дат.
Обоснование: Блокировка даёт понятный 409 и сериализует бронь и обслуживание; EXCLUDE страхует любой путь записи.
Альтернативы: Только проверка в коде — пропускает гонки.

Решение 03

Права менеджера в JWT

+ Плюсы: Нет запроса к БД на каждый запрос; Сервис остаётся stateless
− Компромиссы: Изменённые права действуют после следующего входа — до часа

Решение 04

Инвайт-ссылка вместо временного пароля

Выбор: 32-байтный токен из crypto/rand на 7 дней; пароль менеджер задаёт сам.
Обоснование: Пароль не передаётся в мессенджерах, и администратор его не знает.

Решение 05

Таблица-счётчик номеров

Выбор: order_counters по годам, upsert внутри транзакции заказа.
Обоснование: MAX + 1 повторяет номер удалённого заказа, SEQUENCE оставляет пропуски — для договоров и счетов недопустимо и то и другое.

Следующий · P—03AI-диспетчер задач