CQRS e Event Sourcing em Swift: Arquitetura para Projetos Complexos

Por que a arquitetura tradicional não dá conta das tarefas modernas?

Você já se deparou com uma situação em que adicionar um simples novo recurso em um aplicativo Swift se transforma em um pesadelo? Bugs surgem, dados são perdidos e a lógica cresce a proporções incríveis? Familiar? Bem-vindo ao mundo onde CQRS e Event Sourcing se tornam seus melhores amigos.

Esses padrões não são apenas palavras da moda. São uma forma de pensar que muda radicalmente a abordagem para construir aplicativos em Swift. E hoje vamos analisá-los com exemplos reais. Sem enrolação, sem teorias complicadas — apenas prática.

O que é CQRS? Dividir para conquistar

CQRS (Command Query Responsibility Segregation) é um princípio que diz: "Chega de misturar leitura e escrita na mesma classe". Parece simples, mas as consequências são enormes.

Na arquitetura CRUD (Create, Read, Update, Delete) clássica, você usa um único modelo para tudo. Por exemplo, User. Ele é salvo, lido e atualizado. E se para a leitura forem necessários alguns campos e para a escrita, outros? Começam as gambiarras: campos opcionais, flags, mapeamentos...

O CQRS propõe separar as responsabilidades:

\n
• Comandos (Commands) — alteram o estado. Eles modificam dados, mas não retornam nada.
\n
• Consultas (Queries) — leem dados. Eles não alteram o estado, apenas retornam um resultado.
\n

Em Swift, isso pode ser assim:

// Comando — apenas mutação\nstruct CreateUserCommand {\n    let id: UUID\n    let name: String\n    let email: String\n}\n\n// Consulta — apenas leitura\nstruct GetUserQuery {\n    let userId: UUID\n}\n\n// Manipulador do comando\nclass CreateUserCommandHandler {\n    func handle(_ command: CreateUserCommand) {\n        // Lógica de criação do usuário\n        print("Usuário criado: \\(command.name)")\n    }\n}\n\n// Manipulador da consulta\nclass GetUserQueryHandler {\n    func handle(_ query: GetUserQuery) -> User? {\n        // Lógica de obtenção do usuário\n        return User(id: query.userId, name: "Alexei", email: "alex@example.com")\n    }\n}

Viu? Nenhuma mistura. Cada classe faz exatamente uma coisa. Isso simplifica testes, manutenção e escalabilidade.

Event Sourcing: Armazenando o histórico, não o estado

Agora vamos para o Event Sourcing — um padrão que armazena não o estado atual de um objeto, mas toda a sequência de eventos que levaram a ele.

Imagine uma conta bancária. Em vez de armazenar o saldo (1000 reais), você armazena uma lista de eventos: "Abertura de conta", "Depósito de 500", "Saque de 200", "Depósito de 700". Para saber o saldo atual, você simplesmente reproduz todos os eventos. Isso oferece possibilidades incríveis: auditoria, reversão de alterações, análise.

Vamos implementar isso em Swift:

// Evento\nprotocol Event {}\n\nstruct AccountCreated: Event {\n    let accountId: UUID\n    let initialBalance: Double\n}\n\nstruct MoneyDeposited: Event {\n    let accountId: UUID\n    let amount: Double\n}\n\nstruct MoneyWithdrawn: Event {\n    let accountId: UUID\n    let amount: Double\n}\n\n// Agregado — restaura o estado a partir dos eventos\nclass BankAccount {\n    private(set) var balance: Double = 0\n    private(set) var isActive: Bool = false\n    private(set) var accountId: UUID?\n\n    func apply(_ event: Event) {\n        switch event {\n        case let created as AccountCreated:\n            accountId = created.accountId\n            balance = created.initialBalance\n            isActive = true\n        case let deposited as MoneyDeposited:\n            balance += deposited.amount\n        case let withdrawn as MoneyWithdrawn:\n            balance -= withdrawn.amount\n        default:\n            break\n        }\n    }\n\n    // Restauração a partir do histórico de eventos\n    static func load(from history: [Event]) -> BankAccount {\n        l