Разбор
Агентство артистов, построенное как система
Разбор проекта berlintina.de — того, который принадлежит только ей.
Дипломированный системный инженер со специализацией на ИИ — и человек, которому терминал был домом задолго до появления языковых моделей. Именно в этом разница, которую показывает этот разбор: ИИ-инструменты её не несут, она ими управляет — с дисциплиной, которую оставляет инженерное образование. Архитектура, модель данных и краевые случаи продуманы до первой строки. Дальше — история одного проекта, который она построила одна.
15
SQL-миграций — схема, права, поиск
3
ИИ-сервиса подключено (OpenAI, Gemini, свой слой)
2
Интерфейса: публичный сайт и админ-инструмент
DE · EN
двуязычно, с переключением языка
Задача
Агентство — это не форма обратной связи
Снаружи агентство артистов выглядит как сайт с красивыми фотографиями. На деле это бизнес с двумя сторонами, которые не должны встречаться напрямую: артисты хотят показать себя, организаторы — выбрать. Между ними стоит тот, кто проверяет, — и эта проверка и есть работа.
Очевидным сокращением была бы форма обратной связи, которая шлёт письма. Вместо этого она построила то, что бизнесу действительно нужно: путь для заявок, инструмент для их проверки и каталог, который показывает только одобренное.
Решение 1
Правило видимости живёт в базе данных, а не во фронтенде
Заявка может стать публичной только после одобрения. Это можно решить во фронтенде — условием, которое скрывает непроверенные записи. Выглядит правильно, но таковым не является: тот, кто обращается к API напрямую, всё равно получит всё.
Поэтому в её схеме правило стоит там, где его не обойти. Одна миграция его закрепляет, другая приводит в порядок политики доступа. Это разница между «выглядит безопасно» и «безопасно» — и её замечают на первом же код-ревью.
Решение 2
ИИ берёт на себя разговор, но не решение
Артисты не любят описывать себя в полях формы. Поэтому вводную беседу ведёт языковая модель: она задаёт уточняющие вопросы, формулирует описание шоу и отдаёт готовый текст — подключено несколько провайдеров, чтобы сбой или изменение цен не обрушили продукт.
Важно то, чего модель делать не может. Она не решает вопрос о приёме. Её черновик попадает в инструмент проверки, человек видит страницу ровно такой, какой она станет, правит прямо в ней и одобряет. ИИ — инструмент внутри процесса, а не замена процессу.
Решение 3
Инструмент проверки показывает настоящую страницу, а не таблицу
Большинство админок показывают записи строками. Тот, кто одобряет, видит поля — а не то, что увидят посетители. Ошибки всплывают, только когда они уже опубликованы.
Её админ-панель переворачивает это: она открывается в режиме предпросмотра, показывает готовую страницу, а редактирование кладёт сверху узкой полосой. Правки вносятся на месте, карандашом прямо в тексте. Это не прихоть дизайна, а тормоз для ошибок — одобряешь то, что видишь.
Решение 4
Поиск нужен той стороне, которая платит
Каталог без поиска — это галерея. Но организаторы ищут не имена, а то, что им нужно, — и описывают это своими словами.
Поэтому в её схеме есть полнотекстовый поиск по шоу и отдельная логика сопоставления запроса и предложения. И то и другое — в базе данных, а не в браузерном фильтре: так остаётся быстро, когда пятьдесят записей превратятся в пятьсот.
Что переносится
В этом проекте нет ничего экзотического. Переносится порядок действий: сначала понять, кто пользуется системой и кто за неё платит, — затем модель данных, затем права, затем интерфейс. Именно этот порядок держит, когда проект перерастает голову, которая его начала. И именно поэтому инженер справляется и там, где никто заранее не написал спецификацию.
Проверено по публичному репозиторию · август 2026
Вопросы по архитектуре? info@berlintina.de