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:

domain/

repositories/

user_repository.py

infrastructure/

repositories/

django_user_repository.py

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:

find_active_users()

find_open_opportunities()

find_products_below_stock()

find_overdue_payables()

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.