Data Driven vs Domain Driven

Publicado em 31/10/2019


Recentemente publiquei este vídeo abaixo, no canal do balta.io no YouTube, onde criamos uma API com ASP.NET Core 3 e EF Core 3 em menos de 15 minutos.

Claro que é apenas uma demo, e ainda faltam recursos na API como versionamento, cache, compressão, documentação entre outros, mas se levarmos em conta que no fim temos um cadastro de produtos com categorias, em menos de 15 minutos, é algo de se pensar.

Data Driven

Em alguns vídeos sobre testes de unidade, eu comento que se você “perder tempo” testando a coisa errada, como por exemplo tamanho de campo e outros itens que não são regras de negócio, você terá BEM MENOS tempo para testar o que realmente importa.

Isto é um fato, e algo que assombra muitos projetos que passo, onde o pessoal diz não ter tempo para testar, mas na verdade estão dedicando esforços no lugar errado.

Se não tem regra de negócio, talvez a melhor escolha seja o modelo Data Driven, que nada mais é do que um “espelho” do banco de dados, ou seja, o famoso CRUD.

Se não tem regras, não necessitamos de tantos testes, nem de tanto esforço no domínio. Não é interessante ficar implementando classes, herança, interfaces e várias outras coisas da OOP/SOLID/Clean Code em um cadastro de categoria, de unidade de medida, de estado civil por exemplo.

Seja simples e objetivo no seu código, e se for partir para o modelo Data Driven, minha recomendação é a do vídeo no começo deste artigo, simplesmente criar os modelos, adicionar os Data Annotations e mandar bala! Gerar as migrações, publicar e pronto, API no ar!

Domain Driven

O famoso DDD, onde você vai utilizar tudo que aprendeu sobre OOP, SOLID, Clean Code, padrões e muito mais.

O DDD funciona quando temos regras de negócio, quando temos domínios mais ricos. Aplicar ele em projetos onde você não tem estes requisitos é suicídio.

Imagine um projeto onde você precisa executar cálculos de impostos por exemplo, algo que não pode errar. Com certeza é um cenário para você trabalhar bem no domínio, nas entidades e nos testes de unidade.

Muita gente confunde o uso do DDD com tamanho do projeto. As vezes seu projeto pode ser grande, mas todo orientado a dados, sem regras complexas de negócio. Isto não justifica o uso do DDD.

Então dada a complexidade do seu domínio, aí sim é definido o uso de DDD ou não.

Por que não os dois juntos?

Em diversos projetos que passo a primeira coisa que fazemos é analisar o contexto e domínio da aplicação, em boa parte dos cenários, mais de 50% da aplicação é apenas CRUD, ou sejam, apenas cadastro básicos.

Em um dos últimos projetos que participei recentemente, no fim da análise, chegamos a conclusão que 72% da aplicação eram cadastros básicos, como os que citei, de categoria, unidade de medida e por aí vai, sem regras de negócio.

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.

Com este andamento, ainda sobraram 3 meses de projeto, para aí sim o time focar em DDD, SOLID, Clean Code, criar testes de unidade, trabalhar com calma no que realmente importava.

Conclusão

One size doesn`t fits all (Um tamanho não serve para tudo), ou seja, assim como Data Driven não resolve tudo, DDD também não. E por que não utilizar o melhor dos dois? Fazemos isto com Dapper e EF por exemplo.

A estratégia certa na criação do projeto é o que define o sucesso dele. Pensar fora da caixa, entender que não existe bala de prata, são coisas fundamentais para garantir entregas concisas e de valor.



Compartilhe este artigo

André Baltieri

7x Microsoft MVP

Olá eu sou o André Baltieri, desenvolvedor Web desde 2003, já trabalhei no Brasil e nos EUA, em projetos de diversos tamanhos.

Recebi por sete vezes consecutivas, o prêmio de Most Valuable Professional da Microsoft, um reconhecimento global dado para os maiores influentes em suas tecnologias.

Atuei também como Head of People, recrutando, selecionando e direcionando a carreira de mais de 70 desenvolvedores em uma das melhores empresas para se trabalhar do Brasil.

Sou palestrante em diversos eventos como ASP.NET Conference, DevXperience, TDC, GDG dentre outros e desde 2012 realizo treinamentos e consultorias em diversas empresas do Brasil, acumulando uma ótima experiência que também transformo em cursos InCompany e Online.



Cursos Relacionados



Carreiras Relacionadas