Для кого DomainCraft

Честный разбор: что это за инструмент, чем он отличается от Firebase, PocketBase, JHipster и Retool — и кому он реально нужен, а кому нет.

Если вы впервые слышите про DomainCraft, у вас наверняка возникла одна из трёх мыслей: «Это конструктор сайтов?», «Это облачный бэкенд вроде Firebase?», «Это очередной генератор заглушек?»

Все три ответа неверны — но не случайно. Чтобы понять, для кого DomainCraft, нужно сначала понять, что он делает и, что важнее, чего не делает.

Что такое DomainCraft — простыми словами

DomainCraft — это генератор кода. Не конструктор, не платформа, не облачный сервис. Инструмент, который превращает описание вашего приложения в его исходный код.

Выглядит это так. Вы описываете свою модель в одном текстовом файле domain.yaml:

project:
  name: MyShop

auth:
  type: jwt
  roles: [Admin, User]

entities:
  Product:
    features: [audit, soft_delete]
    fields:
      id: uuid [primary]
      title: string [required, min:3, max:200]
      price: decimal [required, gte:0]
      categoryId: relation(Category) [optional, on_delete:set_null]
    permissions:
      read: ["*"]
      create: [Admin]
      update: ["@Owner", Admin]
      delete: [Admin]

Запускаете одну команду:

domaincraft generate

И получаете полноценный проект исходного кода: модель данных и миграции базы, REST API, авторизацию с JWT, проверку прав, Docker-конфигурацию, тесты. Сегодня — на C#/ASP.NET Core с PostgreSQL. Ядро не привязано к языку: другие языки подключаются как «мосты» — пакеты шаблонов, которые пишутся без изменения ядра.

Ключевое слово здесь — исходный код. Его можно читать, компилировать, запускать у себя, передавать заказчику и продолжать развивать руками, даже если про DomainCraft забудут. Генератор не владеет вашим проектом — он его создаёт и уходит.

Чтобы было с чем сравнивать: карта аналогов

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

1. BaaS — готовый бэкенд как сервис (Firebase, Supabase, PocketBase)

Это бэкенд «из коробки»: база данных, API, авторизация уже работают, вам остаётся подключить фронтенд.

• Firebase — облачный сервис Google. Быстрый старт, готовые SDK для мобильных приложений. Но это проприетарная NoSQL-модель с полным vendor lock: перенести бэкенд на другой хостинг без переписывания нельзя. Цены растут вместе с числом операций чтения/записи.
• Supabase — open-source BaaS на PostgreSQL. Закрывает главные минусы Firebase: SQL, реальный реляционный движок, есть self-hosting. Но самостоятельное развёртывание — это ручное сопровождение стека из десятка Docker-контейнеров, а часть облачных функций проприетарна.
• PocketBase — один бинарный файл, который включает SQLite, REST API, авторизацию и админку. Запустил — и API готов за минуту. Ограничения: только SQLite, масштабирование только вертикальное, кастомная логика — через хуки на Go/JS.

Общее у всех троих: вы не владеете кодом бэкенда. Он живёт в облаке или в бинарнике. Для сложной бизнес-логики приходится встраиваться в чужую экосистему.

2. Low-code платформы (Retool, Appsmith, Budibase)

Инструменты для быстрой сборки внутренних админок и дашбордов поверх уже существующих баз данных. Вы перетаскиваете виджеты, подключаете таблицы, пишете немного JavaScript.

Это не генераторы бэкенда: они создают интерфейс, а не серверный код. Логика исполняется внутри среды платформы. Retool — проприетарный и дорогой SaaS; Appsmith и Budibase имеют open-source версии. Хороши, когда нужна админка за вечер и не нужен собственный бэкенд.

3. Другие генераторы кода (JHipster, Amplication)

Это ближайшие родственники: они тоже создают исходный код.

• JHipster — генератор полного стека на Java/Spring Boot (фронтенд на Angular/React/Vue). Сильная сторона — энтерпрайз-заготовка с тестами. Слабая — генерирует очень много кода и библиотек, которые трудно аудитировать и обновлять после сильной кастомизации.
• Amplication — генератор бэкенда на Node.js (NestJS + Prisma) и .NET. Активно развивается, есть open-source версия. Код следует строгим паттернам платформы, отклоняться от которых сложно — плагинная экосистема задаёт архитектуру.

4. Скелетные шаблоны и контрактные генераторы (dotnet new webapi, OpenAPI Generator)

• Скелетные шаблоны (dotnet new, create-react-app) создают пустую структуру проекта: точку входа, конфигурацию сборки — и всё. Бизнес-логика, таблицы, эндпоинты пишутся с нуля.
• OpenAPI Generator по готовой спецификации API генерирует клиентские SDK или серверные заглушки. Это контракт-первый подход: сначала проектируете API, потом получаете код. Если спецификация меняется, повторная генерация может затереть ручные правки.

Где в этой картине DomainCraft

DomainCraft отличается от всех четырёх категорий тремя вещами.

Первая — исходной точкой является домен, а не API. Вы описываете не эндпоинты, а сущности бизнеса: их поля, связи, правила, права. API, миграции и авторизация выводятся из этой модели автоматически. У BaaS нет исходников вообще; у контрактных генераторов нет домена — есть только спецификация интерфейса.

Вторая — разделение модели и языка. Один и тот же domain.yaml можно отдать разным мостам и получить код на C#, Java или TypeScript. BaaS привязывает вас к своей экосистеме, JHipster — к Java, Amplication — к NestJS/.NET. Здесь мост — это просто пакет шаблонов, а ядро не знает ни одного языка.

Третья — безопасность на второй день (Day-2). Это боль любой кодогенерации: «что будет, если я перегенерирую код после того, как дописал свою логику?» В DomainCraft сгенерированные и ваши файлы никогда не смешиваются: ваши помечаются как «scaffold-once» и никогда не перезаписываются, а сгенерированные свободно обновляются. Движок миграций помнит историю модели: переименуйте сущность или поле — и таблицы в базе переименуются, данные не потеряются.

Для кого DomainCraft на самом деле

Бэкенд-разработчики, которые устали писать одно и то же

Если вы за свою карьеру десять раз создавали CRUD-приложение — репозитории, DTO, контроллеры, миграции, настройку авторизации — вы и есть целевая аудитория. Это инструмент не для тех, кто не хочет писать код, а для тех, кто хочет перестать писать одинаковый код. Усилия уходят в модель и бизнес-логику, а не в каркас.

Команды, которым важно владение кодом и отсутствие привязки

Если ваш проект должен жить десять лет, а решение о стеке может поменяться — важнее, что сгенерированный код принадлежит вам. Нет платформы, от которой вы зависите: есть репозиторий с исходниками, которые вы полностью контролируете. Завтра DomainCraft исчезнет — вы просто продолжите писать C# руками.

Заказная разработка и аутсорс

Заказчику нужен чистый исходный код, который его команда сможет обслуживать без вашего участия. Сгенерированный проект — это обычный ASP.NET Core с обычной архитектурой: в нём нет «следов» генератора. Передать такой проект клиенту честнее, чем привязать его к BaaS или low-code платформе.

Команды, которые хотят один источник правды о модели

Права доступа, валидация, связи и сид-данные описаны в одном файле рядом с сущностями. Это читается, диффается в код-ревью и не расползается по кодовой базе. Для проектов, где модель — главный актив (SaaS, маркетплейсы, внутренние системы), это ощутимая разница.

Разработчики, работающие с ИИ-агентами

Отдельный сценарий: агент описывает домен в domain.yaml, генератор выдаёт 40+ файлов продакшн-кода, агент дописывает бизнес-логику в хуки — и всё запускается. Для ИИ-ассистированной разработки это удобнее, чем позволять агенту писать CRUD с нуля: детерминированный генератор не галлюцинирует одинаковый бойлерплейт.

Для кого DomainCraft НЕ предназначен

Честный ответ на «для кого» невозможен без обратной стороны.

Вам не нужен DomainCraft, если вы делаете MVP и хотите API за одну минуту без компиляции — PocketBase или Supabase быстрее. Если вы фронтенд-разработчик и не хотите вообще знать, как устроен бэкенд — BaaS снимет этот вопрос. Если нужна только админка поверх готовой базы — Appsmith или Retool решат задачу за вечер.

Вам пока не нужен DomainCraft, если вы работаете вне C#/.NET: сегодня есть один готовый мост (csharp-restful), мосты на Java и TypeScript заявлены, но ещё не выпущены. Экосистема молодая, и это стоит учитывать при выборе.

Вам не нужен DomainCraft, если вы не готовы работать с YAML и компилировать сгенерированный проект. Это инструмент для разработчиков: он убирает рутину, но не убирает необходимость понимать свой стек.

Итог

DomainCraft — это инструмент-помощник разработчика, а не конечный продукт. Он не заменяет BaaS, low-code или контрактные генераторы — он занимает свою нишу: генерация владеемого исходного кода из доменной модели.

Если ваша задача — «быстро поднять API и забыть про бэкенд», есть инструменты проще. Если вы пишете бэкенды для жизни, устали от однотипного бойлерплейта и хотите, чтобы модель была единственным источником правды — попробуйте. Один файл, одна команда, и через десять минут у вас компилируемый проект, который полностью ваш.