📚 Pré-requisitos Teóricos: este projeto aplica conceitos ensinados em Módulo 10: Paradigmas e Padrões de Projeto. Recomendado revisar antes de começar.

🏛️ Padrões Repository & Unit of Work em Camada de Domínio

v1.0 — Engenharia de Software & Práticas Profissionais

Trilha de Especialização Pedagógica


🎯 Objetivo & Escopo do Projeto

Implementação corporativa dos padrões Repository e Unit of Work para desacoplar a camada de negócio de frameworks ORM específicos, viabilizando testes unitários atômicos e transações coordenadas.


🛠️ Código de Exemplo da Implementação

class IUnitOfWork:
    def commit(self):
        raise NotImplementedError
    def rollback(self):
        raise NotImplementedError

class UnitOfWorkMemoria(IUnitOfWork):
    def __init__(self):
        self.produtos = []
    def commit(self):
        print("Transacao confirmada via Unit of Work!")
    def rollback(self):
        print("Transacao revertida!")

if __name__ == "__main__":
    uow = UnitOfWorkMemoria()
    uow.produtos.append("Produto Teste")
    uow.commit()


🚀 Como Executar no Laboratório

1. Abra o terminal na pasta deste projeto

No seu editor/IDE, abra a pasta deste projeto (File > Open Folder) ou navegue via terminal:

cd padroes_02_repository_unitofwork

2. Execute a aplicação ou testes

# Executar comandos específicos da tecnologia:
python main.py # ou npm run dev / ./gradlew build

[!TIP] Dica para execução a partir da raiz do repositório: Se você abriu o repositório completo no VS Code, basta navegar até a pasta antes de executar: cd catalogo_projetos/padroes_02_repository_unitofwork


🏛️ Arquitetura Visual & Engenharia do Sistema

A visualização arquitetural abaixo detalha a separação de responsabilidades e o fluxo de dados implementado na subpasta app-python/:

Arquitetura da Aplicação

flowchart TD
    subgraph Entrada["Camada de Entrada & CLI"]
        IN1["Interface de Comando / API"] --> IN2["Parser & Sanitização"]
    end
    subgraph Dominio["Camada de Domínio & Regras"]
        DM1["Modelos de Domínio"] --> DM2["Processamento Algorítmico"]
    end
    subgraph Armazenamento["Persistência & Recursos"]
        ST1["Banco de Dados / Arquivo"] --> ST2["Transações ACID & Logs"]
    end
    subgraph Qualidade["Validação & Qualidade"]
        QA1["Testes Automatizados"] --> QA2["Checkpoints CP-01..05 PASS"]
    end

    Entrada --> Dominio
    Dominio --> Armazenamento
    Armazenamento --> Qualidade

    style Entrada fill:#e3f2fd,stroke:#1976d2,stroke-width:1.5px
    style Dominio fill:#fffde7,stroke:#fbc02d,stroke-width:1.5px
    style Armazenamento fill:#e8f5e9,stroke:#388e3c,stroke-width:1.5px
    style Qualidade fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px

🎯 Engenharia de Requisitos & Modelagem Formal

👤 User Stories (Histórias de Usuário)

ID Persona História de Usuário Critério de Aceite Prioridade
US-01 Arquiteto de Domínio Desejo entidades de domínio totalmente agnósticas de banco de dados Classes de domínio puras sem anotações de ORM ou código SQL Alta
US-02 Engenheiro de Dados Desejo repositório genérico definindo contratos de consulta e escrita Interface Repository com métodos get, add, remove e find_by Alta
US-03 Desenvolvedor Backend Desejo Unit of Work com context manager para transações atômicas with UnitOfWork() assegurando commit em sucesso e rollback em erro Alta
US-04 Especialista em Testes Desejo repositório fake em memória para testes unitários ultrarrápidos Implementação FakeRepository baseada em dicionário em memória Média
US-05 Auditor de Transações Desejo validar que operações parciais sejam desfeitas sob falhas Testes de rollback comprovando invariância do banco após exceções Média

⚙️ Requisitos Funcionais (RF)

ID Descrição do Requisito Criticidade
RF-01 Modelo de domínio desacoplado com validações de invariantes de negócio Alta
RF-02 Interface abstrata Repository e implementação concreta com SQLite Alta
RF-03 Padrão Unit of Work implementado via context manager em Python Alta
RF-04 Mecanismo de rastreamento de mudanças (change tracking) nas entidades Média
RF-05 Suíte de testes automatizados com FakeRepository e SQLite real Média

🛡️ Requisitos Não-Funcionais (RNF)

ID Especificação Arquitetural Criticidade
RNF-01 Garantia formal de propriedades ACID nas transações de domínio Alta
RNF-02 Independência completa entre regras de negócio e infraestrutura Alta
RNF-03 Tempo de execução de testes unitários com FakeRepository inferior a 50ms Média
RNF-04 Uso idiomático de type hints e protocolos em Python 3.8+ Média
RNF-05 Isolamento dos fontes na pasta app-python/ Alta

🔗 Matriz de Rastreabilidade (RTM)

User Story Requisito Funcional Requisito Não-Funcional Módulo / Artefato de Código Status de Homologação
US-01 RF-01 RNF-02, RNF-04 app-python/unit_of_work.py Testado
US-02 RF-02 RNF-02, RNF-03 app-python/unit_of_work.py Testado
US-03 RF-03 RNF-01, RNF-04 app-python/unit_of_work.py Testado
US-04 RF-04 RNF-02, RNF-03 app-python/unit_of_work.py Testado
US-05 RF-05 RNF-01, RNF-05 app-python/unit_of_work.py Testado

🏁 Checkpoints de Qualidade & Homologação

Checkpoint Escopo da Validação Artefato Verificado Status
CP-01 Inicialização & Estrutura de Pastas app-python/ PASS ✅
CP-02 Modelagem de Domínio & Regras Centrais Domain Models PASS ✅
CP-03 Persistência & Operações de I/O Storage / Data PASS ✅
CP-04 Interface de Operação & Usabilidade CLI / GUI / API PASS ✅
CP-05 Homologação com Suíte de Testes Test Suite PASS ✅