Оптимизация структуры моделей Prisma для улучшения читаемости и поддержки

Рассмотрим модель UserAccount, представленную в Prisma Schema. Её текущая структура включает множество полей и связей:

model UserAccount {
  id Int @id @unique @default(autoincrement()) @map("id")
  roles Role[] @default([USER]) @map("roles")
  invitedBy Int? @map("invited_by")
  invitationLinks String[] @map("invitation_links")
  actions UserAction[]
  bookings Booking[]
  notifications Notification[]
  createdProducts Product[] @relation("user_created_products")
  isBlocked Boolean @map("is_blocked")
  blockedBy Int @map("blocked_by")
  blockedAt DateTime @map("blocked_at") @db.Timestamptz()
  blockingReason String @map("blocking_reason") @db.VarChar(128)
  isDeleted Boolean @default(false) @map("is_deleted")
  deletedBy Int @map("deleted_by")
  deletedAt DateTime? @map("deleted_at") @db.Timestamptz()
  deletionReason String? @map("deletion_reason") @db.VarChar(128)
  createdBy Int? @map("created_by")
  createdAt DateTime @map("created_at") @db.Timestamptz()
  updatedBy Int? @map("updated_by")
  updatedAt DateTime? @map("updated_at") @db.Timestamptz()
  tablesAuditLogs TableAuditLog[]
  @@map("user_accounts")
}

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

• Сложность масштабирования: При увеличении количества связей в модели, её восприятие и анализ становятся чрезвычайно затруднительными.
• Отсутствие логической группировки: Нет чёткого разделения между основными бизнес-связями (например, bookings) и техническими или служебными полями. Их смешение в одной схеме усложняет навигацию, хотя разделение без чёткой логики также может привести к потере смысловой целостности модели.

Цель - реорганизовать схемы в интуитивно понятные блоки. Это позволит:

• Сократить время на поиск нужных полей.
• Упростить поддержку и возвращение к коду спустя время.
• Повысить читаемость и ясность структуры данных.

К сожалению, на данный момент визуальных библиотек или общепринятых стандартов для подобной структуризации моделей Prisma практически нет. Это создаёт дефицит готовых решений и примеров, на которых можно было бы основываться или хотя бы черпать вдохновение для организации кода.