Codificando o Molho Secreto

Cada aplicação tem seu molho secreto, sua razão de existir. Codificar o molho secreto é fundamental para escrever aplicações mantíveis e bem-sucedidas.

Espera. O que é codificar? Paciência meu amigo, chegaremos lá.

Primeiro, vamos fazer uma hipótese:

Você acabou de ser promovido a Engenheiro de Software Sênior (Parabéns!). A primeira tarefa do seu CEO é criar um novo produto para a empresa. É uma aplicação contábil do zero. Os executivos acreditam que ter uma solução contábil personalizada lhes dará uma vantagem sobre a concorrência.

Alguns meses se passaram, a maioria das preocupações transversais foram desenvolvidas (parabéns!). O time agora está focado na parte deliciosa da aplicação: o domínio de negócio (o molho secreto). É aqui que a codificação do molho secreto começa.

Codificar é colocar estrutura em torno de um conceito essencial no domínio de negócio.

Em contabilidade, a razão preço (P) lucro (E) (Razão P/L) é uma medida de ganhos de uma empresa. Uma alta razão P/L sugere alto crescimento de ganhos no futuro. A razão P/L é calculada tomando o valor de mercado por ação (preço da ação) dividido pelo lucro por ação (lucro – dividendos / # de ações em circulação).

Uma implementação simples, e eu diria, ingênua:

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

Se isso é usado apenas em um lugar, tudo bem. E se você usar a razão P/L em outras áreas?

Como aqui em PriceEarnings.cs

var priceEarningsRatio = price/earnings;

E aqui em AccountSummary.cs

var priceEarningsRatio = price/earnings;

E aqui em StockSummary.cs

var priceEarningsRatio = price/earnings;

A Razão P/L é central para esta aplicação, mas a forma como é implementada, codificada em vários lugares, faz com que a importância da Razão P/L se perca em um mar de código. É apenas mais uma árvore na floresta.

Você também se abre ao risco de mudar a razão em um lugar mas não em outro. Isso pode afetar cálculos posteriores. Esses tipos de erros são notoriamente difíceis de encontrar.

Frequentemente, testadores assumirão que se funciona em uma área, está correto em todas as áreas. Por que a aplicação não usaria o mesmo código para gerar a Razão P/L em toda a aplicação? Não é esse o ponto da Programação Orientada a Objetos?

Posso imaginar um erro como este chegando à produção e não sendo descoberto até uma visita do seu executivo que exige saber por que os cálculos da Razão P/L da SEC são diferentes do que a empresa apresentou. Esse não é um lugar muito agradável para estar.

Vamos revisitar nossa implementação da razão P/L e ver como podemos melhorar nossa primeira tentativa.

Em sistemas contábeis, fórmulas são uma coisa, vamos colocar estrutura em torno de fórmulas adicionando uma interface:

public interface IFormula
{
    decimal Calculate<T>(T model);
}

Cada fórmula agora é implementada com essa interface, nos dando consistência e previsibilidade.

Aqui está nossa Razão P/L melhorada após implementar nossa interface:

Adicionamos um PriceEarningsModel para passar os dados necessários para nosso método Calculate.

public class PriceEarningsModel
{
    public decimal Price {get; set;}
    public decimal Earnings {get; set;}
}

Usando nosso PriceEarningsModel, criamos uma implementação da interface IFormula para a Razão P/L.

public class PriceEarningsRatioFormula : IFormula
{
    public decimal Calculate<PriceEarningsModel>(PriceEarningsModel model)
    {
        return model.Price / model.Earnings;
    }
}

Agora codificamos a Razão P/L. É um conceito de primeira classe em nossa aplicação. Podemos usá-lo em qualquer lugar. É testável, e uma mudança impacta toda a aplicação.

Como lembrete, aqui está a implementação com a qual começamos:

public class Metric
{
    public string Name { get; set; }
    public decimal Value {get; set}
    public int Order {get; set;}
}
public class AccountingSummary
{
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = price/earnings;
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

É simples e faz o trabalho. O problema é que a Razão P/L, que é um conceito central em nossa aplicação contábil, não se destaca. Engenheiros não familiarizados com a aplicação ou o domínio de negócio não compreenderão sua importância.

Nossa implementação melhorada usa nossa nova classe Razão P/L. Injetamos a classe PriceEarningsRatioFormula em nossa classe AccountSummary.

Substituímos nossa Razão P/L codificada pela nossa nova classe PriceEarningsRatioFormula.

public class AccountingSummary
{
    private PriceEarningsRatioFormula _peRatio;
    
    public AccountingSummary(PriceEarningsRatioFormula peRatio)
    {
        _peRatio = peRatio;
    }
    
    public Metric[] GetMetrics(decimal price, decimal earnings)
    {
        var priceEarningsRatio = _peRatio.Calculate(new PriceEarningsModel 
        { 
            Price = price, 
            Earnings = earnings
        });
        
        var priceEarningsRatioMetric = new Metric 
        {
            Name = "P/E Ratio",
            Value = priceEarningsRatio,
            Order = 0
        }
        return new [] {priceEarningsRatioMetric};
    }
}

Alguém poderia argumentar que há um pouco mais de trabalho com o PriceEarningsRationFormula em comparação com a implementação anterior e eu concordaria. Há um pouco mais de cerimônia, mas os benefícios valem bem o pequeno aumento em código e cerimônia.

Primeiro, ganhamos a capacidade de mudar a Razão P/L para toda a aplicação. Também temos uma única implementação para depurar se surgirem defeitos.

Por último, codificamos o conceito de PriceEarningsRatioFormula na aplicação. Quando um novo engenheiro se junta ao time, ele saberá que fórmulas são essenciais para a aplicação e o domínio de negócio.

Existem outros métodos de codificar (encapsular) o domínio, como microsserviços e assemblies. Cada abordagem tem seus prós e contras, você e seu time terão que decidir o que é melhor para sua aplicação.

Envolver conceitos-chave do domínio em classes e interfaces cria componentes reutilizáveis e limites conceituais. Tornando uma aplicação mais fácil de raciocinar, reduzindo defeitos e diminuindo as barreiras para integração de novos engenheiros.