3.8 KiB
Domain Model
Abordagem de modelação
O domínio deve ser modelado em torno do fluxo operacional do negócio e não apenas em torno de produtos abstratos. A unidade principal de controlo é a encomenda ao fornecedor, a receção, a unidade de inventário e o ciclo de venda/envio.
Entidades principais
User
Representa o utilizador autenticado da aplicação. Na V1 pode existir apenas um utilizador administrador, mas a modelação deve admitir crescimento futuro.
Supplier
Representa um fornecedor de roupa.
Campos indicativos:
- id
- name
- contact_name
- phone
- notes
- created_at
- updated_at
PurchaseOrder
Representa uma encomenda feita a um fornecedor.
Campos indicativos:
- id
- supplier_id
- external_reference
- status
- ordered_at
- expected_at
- notes
- created_at
- updated_at
PurchaseOrderItem
Representa uma linha da encomenda, com artigo, variante e quantidade.
Campos indicativos:
- id
- purchase_order_id
- product_model_id
- variant_label
- size
- color
- sku_supplier
- quantity_ordered
- unit_cost
- notes
Receipt
Representa um evento de receção de mercadoria relativo a uma encomenda.
Campos indicativos:
- id
- purchase_order_id
- receipt_date
- status
- notes
- created_by
- created_at
ReceiptItem
Representa a quantidade recebida de cada linha da encomenda.
Campos indicativos:
- id
- receipt_id
- purchase_order_item_id
- quantity_received
- quantity_rejected
- discrepancy_note
ProductModel
Representa o artigo ou modelo comercial.
Campos indicativos:
- id
- name
- brand
- category
- default_size
- default_color
- internal_sku
- supplier_sku
- notes
- created_at
- updated_at
InventoryUnit
Representa uma unidade concreta ou unidade lógica rastreável no inventário.
Campos indicativos:
- id
- product_model_id
- purchase_order_id
- receipt_item_id
- inventory_status
- condition
- storage_location
- cost_price
- ready_for_listing_at
- created_at
- updated_at
Nota: A V1 deve favorecer rastreabilidade por unidade sempre que possível. Caso existam cenários de stock agregado, essa decisão deve ser explícita e documentada.
Listing
Representa um anúncio publicado ou preparado para publicação.
Campos indicativos:
- id
- inventory_unit_id
- platform
- external_reference
- listing_status
- listed_price
- listed_at
- url
- notes
Customer
Representa o comprador associado a uma venda.
Campos indicativos:
- id
- name
- platform_username
- shipping_name
- shipping_address
- phone
- notes
Sale
Representa a venda de uma unidade ou artigo.
Campos indicativos:
- id
- inventory_unit_id
- customer_id
- sale_channel
- sale_status
- sale_price
- sold_at
- notes
- created_at
Shipment
Representa o envio associado a uma venda.
Campos indicativos:
- id
- sale_id
- shipment_status
- shipped_at
- tracking_code
- carrier
- label_reference
- notes
StatusHistory
Representa o histórico de transições de estado relevantes.
Campos indicativos:
- id
- entity_type
- entity_id
- from_status
- to_status
- changed_by
- changed_at
- note
Relações principais
- Um User pode criar Receipts e alterar estados
- Um Supplier pode ter muitas PurchaseOrders
- Uma PurchaseOrder tem muitos PurchaseOrderItems
- Uma PurchaseOrder pode ter muitas Receipts
- Uma Receipt tem muitos ReceiptItems
- Um ProductModel pode existir em muitos PurchaseOrderItems
- Um InventoryUnit resulta de receção e registo
- Um InventoryUnit pode originar um Listing
- Um InventoryUnit pode estar associado a uma Sale
- Uma Sale pode gerar um Shipment
- As entidades críticas podem gerar StatusHistory
Observações de implementação
- O modelo de dados deve ser implementado em PostgreSQL
- O acesso à base de dados deve ser feito através de Prisma ORM
- As regras de domínio não devem ficar dispersas em componentes de interface