Starter de Modelo de Dados e Limites de Serviço de IA
Defina entidades, relacionamentos de dados e limites de serviço mais limpos antes que o sistema se torne mais difícil de refatorar.
Visão geral do prompt
Parceiro de IA em destaque
Dicas para você
Limites de sistema mais limpos geralmente começam com uma propriedade de domínio mais clara, porque a estrutura do código se torna mais estável quando a responsabilidade é explícita desde cedo.
Da equipe de operaçõesNexusAi TechnologyProblema que resolve
Muitos sistemas tornam-se bagunçados porque as entidades de dados, as responsabilidades e os limites de serviço não são definidos com clareza suficiente no início. Este prompt ajuda os desenvolvedores a pensar em objetos de domínio centrais, propriedade e separação de preocupações mais cedo.
Modelagem de Entidades de Domínio
Esclarece os objetos e relacionamentos centrais em torno dos quais o sistema deve ser construído para que a arquitetura comece a partir de um pensamento de domínio mais limpo.
Mapeamento de Propriedade e Responsabilidade
Torna explícita a propriedade dos dados e a responsabilidade dos componentes para que os sistemas tenham menos probabilidade de desenvolver lógica sobreposta e acoplamento oculto.
Detecção de Risco de Limite
Destaca onde a separação pouco clara, as responsabilidades duplicadas ou os limites de domínio fracos podem criar dívida técnica mais tarde.
Instruções do prompt de IA
Atue como um arquiteto de software especializado em modelagem de domínio, limites de serviço e design de sistema de backend manutenível.
Sua tarefa é ajudar a definir o modelo de dados central, os relacionamentos de entidades e os limites de serviço ou módulo para um sistema de software, de modo que a arquitetura seja mais fácil de implementar e manter.
Contexto:
Uma grande quantidade de dívida técnica começa quando os sistemas são construídos com propriedade de dados pouco clara, separação de domínio fraca ou responsabilidades sobrepostas entre módulos e serviços. Quero uma maneira estruturada de identificar as principais entidades, seus relacionamentos, o que cada parte do sistema deve possuir e onde a confusão de arquitetura futura tem maior probabilidade de aparecer.
INPUTS:
1. Descrição do produto ou sistema
2. Fluxos de trabalho principais
3. Principais papéis de usuário
4. Objetos de dados chave já conhecidos
5. Se o sistema é provavelmente monolítico, modular ou orientado a serviços
6. Incerteza atual sobre propriedade, estrutura ou separação
REQUISITOS DE SAÍDA:
SEÇÃO 1 — Entidades Centrais do Domínio
Liste as entidades mais importantes e seu propósito.
SEÇÃO 2 — Lógica de Relacionamento e Propriedade
Explique como essas entidades se relacionam e quem deve possuir o quê.
SEÇÃO 3 — Limites de Serviço ou Módulo
Recomende como o sistema deve ser separado logicamente.
SEÇÃO 4 — Notas de Risco de Fluxo de Dados
Destaque áreas onde o acoplamento, a duplicação ou a propriedade pouco clara podem se tornar um problema.
SEÇÃO 5 — Estrutura Final do Blueprint
Apresente um design conciso de dados e limites que possa guiar a implementação.
REGRAS:
- Otimize para manutenibilidade e separação de preocupações
- Evite complexidade artificial quando um modelo claro for suficiente
- Torne a propriedade e a responsabilidade explícitas
- Mantenha a saída útil para o trabalho de design de backend ou full-stack real
Resultado esperado
Um starter de arquitetura estruturado mostrando entidades centrais, lógica de propriedade, limites de módulo ou serviço e riscos de fluxo de dados que ajudam a prevenir problemas futuros de acoplamento.
Jornada de implementação
Descreva o sistema e seus fluxos de trabalho principais
Forneça a ideia do produto, os papéis do usuário, os fluxos de trabalho importantes e quaisquer objetos de domínio conhecidos para que o modelo possa ser construído em torno do sistema real, em vez de entidades abstratas.
4–6 minutosGere o modelo estrutural e os limites
Execute o prompt no ChatGPT ou Claude para identificar entidades, propriedade e sugestão de separação de módulo ou serviço. Foque especialmente na lógica de propriedade, pois é onde muitos problemas futuros de arquitetura se originam.
6–10 minutosUse a saída antes de travar o design do banco de dados ou serviço
Revise os riscos de fluxo de dados e as notas de separação antes do início da implementação para que a estrutura do backend tenha uma chance melhor de permanecer manutenível à medida que o produto cresce.
5–10 minutos