Data Driven vs Domain Driven

Menos regras, menos esforço no domínio

Se não há regras, não precisamos de tantos testes nem de tanto esforço no domínio. Então, não faz sentido implementar classes, herança, interfaces e outros recursos de OOP, SOLID e Clean Code em um cadastro simples.

Pense, por exemplo, em um cadastro de categoria, de unidade de medida ou de estado civil. Em todos eles, o trabalho se resume a gravar, listar, editar e excluir registros.

Seja simples e objetivo no seu código, porque nem tudo precisa de Domain Driven. Se for partir para o modelo Data Driven, minha recomendação é a do vídeo no começo deste artigo.

Ou seja, crie os modelos, adicione os Data Annotations e mande bala! Depois, gere as migrações, publique e pronto, API no ar!

Como fica um cadastro Data Driven no código

Um modelo Data Driven costuma ser apenas uma classe com propriedades e validações declarativas. Veja um exemplo de categoria no estilo do vídeo.

public class Category
{
    [Key]
    public int Id { get; set; }

    [Required(ErrorMessage = "This field is required")]
    [MaxLength(60, ErrorMessage = "This field must have up to 60 characters")]
    public string Title { get; set; }
}

Em seguida, o controller conversa direto com o DbContext do Entity Framework Core, sem camadas intermediárias.

[HttpPost]
public async Task<ActionResult<Category>> Post(
    [FromServices] DataContext context,
    [FromBody] Category model)
{
    if (!ModelState.IsValid)
        return BadRequest(ModelState);

    context.Categories.Add(model);
    await context.SaveChangesAsync();
    return model;
}

Repare que não existe regra de negócio aqui, por isso o modelo Data Driven resolve o problema sem esforço extra. As únicas validações são de formato, e o próprio ASP.NET Core cuida delas por meio dos atributos.

Se quiser ver esse estilo aplicado passo a passo, confira a série sobre APIs Data Driven com ASP.NET Core 3 e EF Core 3.

Tamanho do projeto não define DDD

Muita gente confunde o uso do DDD com o tamanho do projeto. Às vezes o projeto é grande, mas todo orientado a dados, sem regras complexas de negócio.

Nesse caso, o tamanho sozinho não justifica o DDD. Então, é a complexidade do domínio que define a escolha entre Data Driven ou Domain Driven.

Um sistema com cem telas de cadastro simples continua sendo um sistema Data Driven. Por outro lado, um módulo pequeno de cálculo fiscal pode exigir toda a disciplina do Domain Driven.

Como fica uma entidade Domain Driven no código

Em um modelo Domain Driven, a entidade deixa de ser só um saco de propriedades. Em vez disso, ela protege as próprias regras e só aceita mudanças válidas.

public class Invoice
{
    private readonly List<InvoiceItem> _items = new List<InvoiceItem>();

    public Invoice(decimal taxRate)
    {
        // a alíquota precisa estar entre 0% e 100%
        if (taxRate < 0 || taxRate > 1)
            throw new ArgumentOutOfRangeException(nameof(taxRate));

        TaxRate = taxRate;
    }

    public decimal TaxRate { get; private set; }
    public IReadOnlyCollection<InvoiceItem> Items => _items;

    public void AddItem(string description, decimal price, int quantity)
    {
        // regra de negócio: não existe item com quantidade ou preço inválidos
        if (quantity <= 0 || price <= 0)
            throw new InvalidOperationException("Invalid item");

        _items.Add(new InvoiceItem(description, price, quantity));
    }

    public decimal Subtotal() => _items.Sum(x => x.Price * x.Quantity);

    public decimal Tax() => Math.Round(Subtotal() * TaxRate, 2);

    public decimal Total() => Subtotal() + Tax();
}

public class InvoiceItem
{
    public InvoiceItem(string description, decimal price, int quantity)
    {
        Description = description;
        Price = price;
        Quantity = quantity;
    }

    public string Description { get; private set; }
    public decimal Price { get; private set; }
    public int Quantity { get; private set; }
}

Note que os setters são privados e que o cálculo do imposto mora dentro da entidade. Assim, nenhuma parte da aplicação consegue montar uma nota inválida por acidente.

Como a regra fica isolada, testar o cálculo também fica simples e rápido.

public class InvoiceTests
{
    [Fact]
    public void Should_calculate_tax_over_subtotal()
    {
        var invoice = new Invoice(0.1m);
        invoice.AddItem("Course", 100m, 2);

        Assert.Equal(20m, invoice.Tax());
        Assert.Equal(220m, invoice.Total());
    }
}

Esse é o tipo de teste que vale ouro. Para começar a escrever testes assim, veja os fundamentos dos testes de unidade.

Gerando os cadastros com T4 Templates

O que fizemos? Em um dia e meio, geramos todos os CRUDs via T4 Templates, já com as views em um projeto separado.

Ou seja, em um dia e meio tínhamos mais de 70% do projeto concluído.

O T4 é o mecanismo de templates de texto do Visual Studio. De acordo com a documentação oficial do T4, ele gera código a partir de um modelo, que pode ser um arquivo ou até um banco de dados.

Esse encaixe é perfeito para o lado Data Driven, enquanto o Domain Driven fica reservado para as regras. Afinal, se os cadastros são espelhos das tabelas, a própria estrutura do banco serve como modelo para gerar o código.

Além disso, a Microsoft recomenda gerar classes parciais nesses cenários. Dessa forma, o time consegue complementar o código gerado sem perder as alterações na próxima geração.

Foco total onde o domínio importa

Com esse andamento, ainda sobraram três meses de projeto. Então, o time pôde focar em DDD, SOLID e Clean Code, criar testes de unidade e trabalhar com calma no que realmente importava.

Esse é o grande ganho de escolher entre Data Driven ou Domain Driven conforme a necessidade de cada parte. O esforço sai dos cadastros repetitivos e vai para as regras que geram valor.

O guia da Microsoft mostra a mesma estratégia na aplicação de referência eShopOnContainers. Nela, os serviços de catálogo, carrinho e perfil seguem como CRUD, enquanto o serviço de pedidos aplica padrões de DDD.

Inclusive, o guia afirma que um modelo anêmico não é antipadrão em um serviço CRUD. Ele só vira problema quando o domínio tem muitas regras de negócio em constante mudança.

Como decidir entre Data Driven ou Domain Driven em cada módulo

Para tomar a decisão módulo a módulo, algumas perguntas ajudam bastante.

• O módulo tem regras que mudam com frequência ou dependem de especialistas do negócio?
• Um erro nesse módulo gera prejuízo financeiro, fiscal ou jurídico?
• As operações vão além de gravar, listar, editar e excluir registros?
• Existem invariantes, ou seja, condições que nunca podem ser violadas?

Se a maioria das respostas for "não", o caminho Data Driven tende a ser suficiente.

Por outro lado, se a maioria for "sim", vale investir no Domain Driven.

Também é possível começar simples e evoluir. Quando um cadastro passa a ganhar regras, você migra apenas aquele módulo para um modelo de domínio mais rico.