Skip to main content
Para que a equipe de engenharia compreenda visualmente como o banco de dados relaciona as categorias críticas (Tenants, Produtos, Kits, e Integrações), desenvolvemos o modelo lógico abaixo.

​
1. Diagrama Entidade-Relacionamento Core

Por conta do padrão Domain-Driven Design (DDD), as entidades se relacionam não pelo acoplamento forçado, mas pelas raízes de Agregação. Observação Crítica: A variável tenant_id atua como Chave Composita ou Foregin Key mandátoria em praticamente todas as tabelas.

​
2. Dicionário de Restrições Arquiteturais

​
Multi-Tenancy (Isolamento de Dados)

  1. Gatilhos de Inserção: Graças ao TenantSubscriber (TypeORM), a equipe de Dev não precisa passar o tenantId nos métodos de create() de Product, InventoryBalance, etc. É injetado por reflexão do CLS-Hooked.
  2. Índices Compostos de Proteção: Todas as queries que buscam unicidade (Exemplo: “Existe SKUs duplicados?”) obrigatoriamente possuem um @Index(unique: true) não no SKU sozinho, mas sim no bundle (tenant_id, sku).

​
Agregações do Catálogo (Product e KitComponent)

A API de leitura do produto lista os componentes, mas observe no ERD que KIT_COMPONENT faz referência reflexiva apontando sempre para um Product.
  • kit_id: Referencia a linha do Produto com tipo = KIT.
  • component_id: Referencia a linha do Produto com tipo = SIMPLE. Não é permitido que o component_id aponte para outro KIT (evita recursividade infinita cíclica que travaria os workers de custo médio e baixa de estoque).

​
Segurança e Criptografia (Tokens OAuth)

MARKETPLACE_APP_TOKEN nunca armazena textos puros! Todo access_token fornecido pela Shopee ou Mercado Livre é interceptado no TokenService e escrito no banco usando Criptografia AES de 256 bits, usando a chave Mestra .env(TOKEN_ENCRYPTION_KEY). O ERD acusa a coluna como acccessTokenEncrypted para forçar este mindset em manutenções de DBA.