Перевод идей в компоненты системы

Для создания сложнейшей цифровой системы не нужно писать ни одной строчки кода, достаточно лишь дать точные имена вещам, которые еще не существуют.

Когда мы используем метод Spec-First, наша главная задача — не программировать, а проектировать. Проектирование — это процесс разделения монолитной «идеи» в вашей голове на четкие, независимые детали. Если вы скажете Claude: «Сделай мне приложение для библиотеки», ИИ может создать сотни разных вариантов. Но если вы разложите эту библиотеку на конкретные составляющие, вы получите именно то, что задумали.

Представьте, что вы строите дом из конструктора. Вы не можете просто сказать «хочу дом». Вам нужны кирпичи, окна, двери и понимание того, кто в этом доме будет жить. В системном проектировании такие «детали» называются компонентами. Мы будем использовать модель UDAR (Users, Data, Actions, Representations), чтобы превратить любую абстрактную мечту в четкий чертеж.

Кто управляет системой: Акторы (Пользователи)

Первый шаг декомпозиции — определить, кто будет взаимодействовать с системой. В системной логике мы называем их «Акторами». Актор — это не обязательно человек. Это может быть другая программа, датчик или даже автоматический таймер. Главное свойство Актора — наличие прав доступа и определенных целей.

Почему это важно? Потому что логика системы меняется в зависимости от того, кто совершает действие. Например, в банковском приложении Клиент может видеть свой баланс, а Менеджер банка — балансы всех клиентов. Ошибка на этом этапе приводит к тому, что система становится небезопасной или неудобной.

Когда вы описываете Актора, думайте не о его имени, а о его роли. Какую проблему он решает внутри системы? Какие данные ему разрешено видеть? Какие действия ему запрещены? Четкое разделение ролей — это фундамент, на котором держится вся архитектура.

Что хранится внутри: Сущности (Данные)

Данные — это «память» вашей системы. Если Акторы — это живые существа, то Данные — это неодушевленные предметы, которыми они манипулируют. В методе Spec-First мы называем их Сущностями. Сущность — это описание объекта, который система должна запомнить.

Возьмем пример с кофейней. Что здесь будет данными? «Заказ», «Напиток», «Ингредиент». У каждой сущности есть свойства. У «Заказа» есть время создания, статус и цена. У «Напитка» есть название и объем.

Важно понимать: данные в системе статичны, пока на них не направлено действие. Они лежат в «хранилище» и ждут своего часа. Правильное описание данных позволяет Claude понять, какую структуру базы данных нужно создать, даже если вы не знаете, что такое база данных.

Как система живет: Операции (Действия)

Действие — это то, что связывает Актора и Данные. В нашей модели это «глаголы». Что Актор может сделать с Сущностью?

Например, Актор «Покупатель» может выполнить действие «Добавить в корзину» над сущностью «Товар». Это действие меняет состояние системы. Раньше товар был просто в каталоге, теперь он закреплен за конкретным пользователем в его корзине.

При описании действий критически важно думать о правилах (бизнес-логике). Можно ли добавить в корзину товар, которого нет в наличии? Можно ли отменить заказ, если он уже передан курьеру? В методе Spec-First вы описываете эти правила словами. Claude переведет эти логические запреты и разрешения в строгие алгоритмы. Если вы не опишете действие, система будет «мертвой» — картинкой, на которой ничего не нажимается.

Что видит пользователь: Представления (Интерфейсы)

Представление — это «окно», через которое Актор смотрит на Данные и совершает Действия. Это не просто дизайн или красивые кнопки. Это способ группировки информации.

Одно и то же данное может выглядеть по-разному. Сущность «Заказ» для Покупателя выглядит как карточка с кнопкой «Отменить». Для Повара та же сущность «Заказ» выглядит как строка в списке дел с кнопкой «Готово».

Когда мы проектируем Представления, мы не рисуем их в Figma. Мы описываем логику: «На этом экране пользователь должен видеть свои последние три заказа и иметь возможность нажать на любой из них, чтобы увидеть детали». Это и есть Spec-First подход — описание функциональной необходимости представления до того, как мы решим, какого цвета будет кнопка.

Атомарная декомпозиция: до какого уровня дробить?

Новичков часто пугает вопрос: насколько мелко нужно разбивать идею? Ответ кроется в понятии «Атомарности». Компонент считается атомарным, если его нельзя разделить дальше без потери смысла.

Если вы описываете сущность «Пользователь», не нужно на первом этапе описывать его «Фамилию» как отдельную сущность. Фамилия — это свойство пользователя. Но если вы делаете систему для генеалогического древа, то «Родственная связь» — это уже отдельная сущность, потому что она соединяет двух людей.

Главный секрет успеха в вайбкодинге с Claude — это соблюдение баланса. Вы должны дать Claude достаточно структуры, чтобы он не гадал, но оставить достаточно свободы, чтобы он мог предложить оптимальную техническую реализацию. Декомпозиция — это не написание кода, это создание карты. А карта должна быть точной, но не в масштабе 1:1.

Реальное применение: От идеи к чертежу

Когда вы садитесь за написание спецификации для Claude, начните с чистого листа. Запишите в четыре колонки: кто будет пользоваться системой, какие объекты в ней существуют, что с ними можно делать и какие экраны нужны.

Этот процесс часто называют «инвентаризацией смысла». Например, при создании трекера привычек вы обнаружите, что «Привычка» — это данные, а «Отметка о выполнении» — это действие, которое создает новое данное (запись в календаре). Без этого разделения вы получите хаотичный код, который сложно менять. С этим разделением — вы становитесь архитектором, который управляет сложностью системы одним лишь ясным описанием.

В следующем уроке мы увидим, как Claude превращает эти абстрактные компоненты в реальную структуру файлов на вашем компьютере. Вы поймете, что папки и файлы — это просто физические контейнеры для той логики, которую вы только что научились проектировать.