- Marcelo Areco reviewers: [] created: 2026-07-02 updated: 2026-07-02 tags:
- ddd
- repositories
- persistence
Repositories¶
Objetivo¶
Definir o padrão oficial para implementação de Repositories na CoreFlow Platform.
Repositories são responsáveis por abstrair completamente o mecanismo de persistência, permitindo que o domínio permaneça independente de banco de dados, ORM e infraestrutura.
Conceito¶
Um Repository representa uma coleção de Aggregates.
Sua responsabilidade é fornecer acesso às entidades do domínio, ocultando detalhes de persistência.
Responsabilidades¶
Todo Repository deverá:
- recuperar Aggregates;
- persistir Aggregates;
- remover Aggregates (Soft Delete quando aplicável);
- executar consultas específicas do domínio;
- ocultar detalhes do ORM.
Arquitetura¶
Application Service
│
▼
Repository Interface
│
▼
Repository Implementation
│
▼
Django ORM
│
▼
PostgreSQL
Interfaces¶
Os Repositories deverão ser definidos no domínio.
As implementações deverão existir na camada de infraestrutura.
Exemplo:
Repositories do Core¶
- UserRepository
- CompanyRepository
- RoleRepository
- PermissionRepository
- AuditRepository
- NotificationRepository
- FileRepository
Repositories do CRM¶
- LeadRepository
- ContactRepository
- AccountRepository
- OpportunityRepository
- ActivityRepository
- ProposalRepository
Repositories do ERP¶
- ProductRepository
- SupplierRepository
- PurchaseRepository
- InventoryRepository
- SalesRepository
Repositories Financeiros¶
- PayableRepository
- ReceivableRepository
- PaymentRepository
Métodos Básicos¶
Todo Repository deverá fornecer, quando aplicável:
- get_by_id()
- find()
- list()
- exists()
- save()
- delete()
- restore()
Consultas¶
Consultas deverão representar linguagem do domínio.
Exemplos:
Evitar consultas genéricas.
Regras¶
Repositories nunca deverão:
- conter regras de negócio;
- executar validações do domínio;
- publicar eventos;
- controlar autenticação;
- controlar autorização.
Persistência¶
O domínio nunca deverá conhecer:
- Django ORM
- SQL
- PostgreSQL
- Redis
- Elasticsearch
Toda persistência deverá ser abstraída.
Unit of Work¶
Quando necessário, múltiplos Repositories deverão participar da mesma transação através de um Unit of Work.
Testabilidade¶
Repositories deverão permitir:
- Mock
- Fake
- InMemory Repository
Facilitando testes unitários.
Diagrama¶
classDiagram
ApplicationService --> UserRepository
ApplicationService --> CompanyRepository
ApplicationService --> OpportunityRepository
UserRepository <|.. DjangoUserRepository
CompanyRepository <|.. DjangoCompanyRepository
OpportunityRepository <|.. DjangoOpportunityRepository
Anti-patterns¶
É proibido:
- SQL dentro do domínio.
- Regras de negócio no Repository.
- Controllers acessando ORM diretamente.
- Services acessando Models diretamente.
- Dependência do domínio em Django.
Objetivo Final¶
Garantir uma camada de persistência desacoplada, reutilizável, testável e alinhada aos princípios de Domain-Driven Design e Clean Architecture, preservando a independência do domínio em relação à infraestrutura.