ENTITY_NAME в пути — placeholder каталога вашей сущности, например product для Product; EntityName — её тип в коде. Подставьте фактические имена своего проекта. Примеры Article ниже показывают отдельную сущность, а не обязательный модуль любого приложения.
Эти решения определяют, где вносить изменения и какие зависимости поддерживать. В таблице показаны их польза и ограничения: что генератор упрощает, а что остаётся задачей команды.
Модульный монолит
Прикладные сценарии разделены на пакеты, но собираются в один backend. Это уменьшает объём межсервисной инфраструктуры. Чтобы выпускать или масштабировать модули независимо, потребуется изменить архитектурные границы — одной новой папки недостаточно.
backend/internal/app/<entity>/
Интерфейсы задаёт потребитель
App объявляет Repository и Hooks, а bootstrap передаёт реализации. Прикладной сценарий не зависит от конкретного PostgreSQL-адаптера. Цена этого разделения — явные интерфейсы и код сборки, которые нужно поддерживать согласованно.
app/ENTITY_NAME/service.go
generated/bootstrap/app.go
Явный SQL и pgx
SQL-запросы и преобразование строк видны в исходниках, без дополнительного слоя ORM. Их поведение можно изучить напрямую. При этом работа со специфичными возможностями PostgreSQL и сложными запросами требует знания SQL и устройства БД.
adapters/postgres/generated/ENTITY_NAME_repository.go
ENTITY_NAME_queries.sql
UI рядом с сущностью
Форма, список, типы и custom-компоненты Article находятся в одной feature. Общий код переиспользуется через shared. Сценарии между несколькими сущностями нужно связывать явно, не создавая произвольные взаимные импорты.
admin/src/features/ENTITY_NAME/
Custom-файлы сохраняются
Правило seed_if_missing создаёт файл только при отсутствии и сохраняет существующую реализацию. Но контракт может измениться вместе с моделью. Совместимость расширений и полностью заменённых страниц проверяет и поддерживает разработчик.
backend/internal/custom/
features/ENTITY_NAME/custom/
История SQL продолжается новыми шагами
Изменения схемы оформляются следующими миграциями, а не переписыванием прежних. По истории видно, как БД переходила между состояниями. Сложные преобразования данных и их восстановление всё равно требуют отдельного плана.
backend/migrations/
Одна декларативная модель
Backend, стандартный UI и OpenAPI создаются из общего описания. Типовые возможности настраиваются в Generator UI или через CLI, а особенности приложения реализуются в custom. Генерация повторяема в пределах тех возможностей, которые поддерживает модель.
.admingen/project.yaml
В генераторе: internal/domain/normalized/ и templates/