Arquitetura Limpa em Go – Parte 3 – Refatorando

Nessa terceira parte da série sobre arquitetura limpa em Go, vamos falar sobre um tema que pode ser um verdadeiro game changer para os seus projetos: a refatoração para a Arquitetura Limpa. Quem já é dev faz tempo sabe que nem sempre começamos com a arquitetura ideal. Às vezes, herdam-se códigos que são verdadeiros labirintos. E daí entra a refatoração.

O Desafio: Entendendo o Código Existente

A refatoração começa com um entendimento profundo do que já temos. Muitas vezes, nos deparamos com códigos que cresceram de forma orgânica, sem muita atenção à arquitetura ou padrões de design. Esses códigos podem funcionar, mas a longo prazo, tornam-se difíceis de entender, testar e manter.

O Plano de Refatoração

Refatorar é mais do que codificar; é repensar e reestruturar. Para isso, é essencial ter um plano claro, que inclua:

• Análise Completa das Entidades e Casos de Uso: Essa é a fase de desmembrar o sistema em componentes menores e mais gerenciáveis. Identifique claramente quais são as entidades (modelos de dados) e os casos de uso (lógica de negócio).
• Interfaces e Abstrações Estratégicas: As interfaces em Go são muito poderosas para desacoplar e organizar o código. Elas permitem maior flexibilidade e testabilidade.

Refatoração Detalhada: Transformando o Código

1. Isolamento da Lógica de Negócios: Essa etapa envolve extrair a lógica de negócios de outros aspectos, como UI ou acesso a dados. O objetivo é criar funções e métodos focados e coesos, que façam apenas uma coisa e a façam bem. Lembram dos princípios de SOLID?
2. Implementação de Repositórios e Serviços: Aqui, abstraimos o acesso a dados e as operações de negócio em repositórios e serviços. Isso nos ajuda a manter nosso código modular e a simplificar os testes.
3. Adotando a Injeção de Dependência: Em Go, podemos aplicar injeção de dependência de forma elegante, sem a necessidade de frameworks complexos. Isso traz flexibilidade e facilita os testes unitários.
4. Testes Refinados e Abordagem TDD (Test-Driven Development): A refatoração é o momento perfeito para adotar TDD ou aprimorar nossos testes. Escrever testes antes do código nos ajuda a manter o foco na funcionalidade e na qualidade.

Vamos detalhar mais nosso exemplo anterior:

Antes da Refatoração:

// GetUser busca um usuário diretamente do banco de dados
func GetUser(id int) (*User, error) {
    // Implementação direta de acesso ao banco
}

Depois da Refatoração:

// UserRepository define a interface para operações de usuário
type UserRepository interface {
    GetUser(id int) (*User, error)
}

// UserManager gerencia operações relacionadas aos usuários
type UserManager struct {
    repo UserRepository
}

// NewUserManager cria uma instância de UserManager
func NewUserManager(repo UserRepository) *UserManager {
    return &UserManager{repo: repo}
}

// GetUser encapsula a lógica de obter um usuário
func (m *UserManager) GetUser(id int) (*User, error) {
    return m.repo.GetUser(id)
}

Neste exemplo, demonstramos como a lógica de negócios é claramente desacoplada dos detalhes de implementação. Isso não só melhora a testabilidade, mas também torna o código mais legível e fácil de manter.

Conclusão

Ao final deste processo, o que temos é um código que não apenas funciona de forma eficiente, mas é clean e prazeroso de trabalhar. A refatoração para a Arquitetura Limpa pode ser desafiadora, mas valerá a pena.

No próximo post da série vamos falar sobre padrões de projeto em uma arquitetura limpa. Stay tuned.

Let’s code!