Aula 20 - Projeto Capstone: Arquitetura de Software Modular Autônoma 🏆

📑 1. Fundamentos Teóricos & Análise Técnica

O Projeto Capstone de Paradigmas e Padrões de Projeto convida o estudante a sintetizar toda a sabedoria da engenharia de software em um projeto integrado. O desafio consiste em projetar e implementar o núcleo de uma Plataforma de E-Commerce com Múltiplos Meios de Pagamento e Notificações.

O sistema exige a aplicação prática dos seguintes padrões: 1. Padrão Strategy (GoF): Para selecionar dinamicamente algoritmos de cálculo de frete e liquidação de pagamentos (Cartão de Crédito, Pix, Boleto). 2. Padrão Observer / Mediator: Para comunicação desacoplada entre a confirmação do pedido e a emissão de notificações. 3. Padrão Factory Method: Para instanciação encapsulada de entidades complexas e canais de notificação. 4. Clean Architecture e Value Objects: Isolamento total entre domínio e infraestrutura, eliminando a dependência direta de bancos de dados ou frameworks externos.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Client["Checkout Service"] --> Factory["PaymentStrategyFactory (Factory Method)"]
    Factory --> Strategy{"Estratégia Escolhida"}
    Strategy -->|PIX| Pix["PixPaymentStrategy"]
    Strategy -->|Cartão| Card["CreditCardStrategy"]
    Pix & Card --> Processor["Processador Transacional"]
    Processor --> Mediator["Event Mediator (Observer)"]
    Mediator --> Email["Serviço de E-mail"]
    Mediator --> Audit["Serviço de Auditoria"]
    style Client fill:#e1f5fe,stroke:#01579b
    style Factory fill:#fff3e0,stroke:#e65100
    style Strategy fill:#e8f5e9,stroke:#2e7d32
    style Mediator fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Princípio Aberto-Fechado (OCP): Novos meios de pagamento são adicionados criando novas classes Strategy sem alterar o código existente. - Inversão de Dependência (DIP): O processador depende de interfaces abstratas (IPaymentStrategy), nunca de implementações concretas. - Alta Coesão e Baixo Acoplamento: Módulos que podem ser testados isoladamente com mocks simples. - Manutenibilidade de Longo Prazo: Redução drástica do custo de refatoração para novos requisitos de negócio.

🛠️ 2. Implementação Prática em Padrões de Projeto e Clean Architecture

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// payment_strategy.ts (Implementação do Padrão Strategy e Factory)
// Interface Strategy
export interface IPaymentStrategy {
  pay(amount: number): Promise<boolean>;
}

export class PixPaymentStrategy implements IPaymentStrategy {
  async pay(amount: number): Promise<boolean> {
    console.log(`[PIX] Gerando QR Code dinâmico para R$ ${amount.toFixed(2)}`);
    return true;
  }
}

export class CreditCardPaymentStrategy implements IPaymentStrategy {
  async pay(amount: number): Promise<boolean> {
    console.log(`[Cartão] Transacionando R$ ${amount.toFixed(2)} na operadora`);
    return true;
  }
}

// Factory para seleção desacoplada da estratégia
export class PaymentStrategyFactory {
  static getStrategy(type: 'pix' | 'credit_card'): IPaymentStrategy {
    switch (type) {
      case 'pix': return new PixPaymentStrategy();
      case 'credit_card': return new CreditCardPaymentStrategy();
      default: throw new Error(`Meio de pagamento não suportado.`);
    }
  }
}

💡 Análise Passo a Passo do Código

1. Contrato Unificado IPaymentStrategy: Define a operação essencial que todas as formas de pagamento devem implementar.
2. Encapsulamento com Factory: O cliente não sabe como a estratégia é instanciada, apenas solicita pelo identificador type.
3. Conformidade com Princípios SOLID: Permite plugar novas formas de pagamento (como criptomoedas ou boleto) criando apenas uma nova classe.

🎯 3. Próximos Passos & Sequência Didática