Essa vem de um excelente post do MVP Greg Young (que é um dos poucos MVPs que eu vejo falando enfaticamente de DDD e arquitetura), e de uma discussão que tivemos na última reunião do .Net Architects.

O Greg coloca, com propriedade, que a Microsoft está recomendando um modelo anêmico, através das suas recomendações de aplicações em duas camadas com REST, ou de três camadas com Web. Ou seja, uma reclamação diretamente ligada à arquitetura.

É verdade? É. Querem prova? Eu provo. Vejam estas colocações, tiradas destes documentos:

1. “Business rules are not implemented within the business entities.” (Regras de negócio não são implementadas nas entidades de negócios.)
2. “Business operations that need to be included in a transaction are combined in a single operation exposed by a business process object that implements the transaction script pattern.” (Operações de negócios que precisam ser incluidas em uma transação são combinadas em uma única operação exposta por um processo de negócio que implementa o padrão “transaction script”.)
3. “Within the transaction script operation a transaction is started, one or more business operations are performed, and the transaction is committed or rolled-back based on the outcome of the business operations.” (Dentro de operações de “transaction script” uma transação é iniciada, uma ou mais operações de negócio são realizadas, e a transação é completada ou revertida, baseada no resultado das operações de negócio.)

Realmente as recomendações presentes nestes dois documentos levam a aplicação a utilizar um modelo anêmico. Isso é um problema?

Lendo o excelente livro do Fowler PoEAA (review disponível na minha seção de livros recomendados) você ve a descrição do padrão transaction script, assim como vê os padrões table module e active record também. Há problema em utilizar estes padrões? Não, não há. Porque a reclamação então?

Bom, lendo-se a reclamação do Fowler sobre modelos anêmicos (link acima), você logo entende. Resumindo para quem estiver sem tempo: mapear dados relacionais para objetos dá o maior trabalho, e não utilizar um design OO, que une dados e comportamento, para dar lugar a um padrão procedural, como é o caso do transaction script, além de criar um bruta samba do criolo doido, é muito improdutivo. Se você vai trabalhar procedural, não faz sentido ficar criando um modelo de domínio todo bem planejado, faz mais sentido falar logo a lingua dos dados, como por exemplo relacional (maioria dos BDs), ou hierárquico (como no xml). Nada contra transaction scripts, só não chame isso de OO.

E porque este post se chama “evangelismo de código procedural”? Porque, conforme bem colocado na nossa última reunião do .Net Architects, e também pelo Mr. Young, esses padrões vão ser seguidos pela maior parte do mercado. Ah… isso sim é um problema. Não é um problema que a Microsoft publique sugestões de padrões, mas sim que publique sugestões que vão criar aplicações com deficiências, como são estes casos. Neste caso, o P&P faz um grande desserviço ao trabalhar com o foco nos dados, e ainda sugerir um ORM (Entity Framework) que usa Objetos, e um código procedural (transaction script). Também não gosto que a Microsoft faça evangelismo de código altamente procedural a desenvolvedores de software que ouvem a anos que devem trabalhar com OO. Vai causar uma tremanda dor de cabeça. Então, estou aqui, dando continuidade ao inconformismo do Greg, e acrescentando o meu próprio.

E vocês querem saber? They know better. A Microsoft possui mentes brilhantes, e oferecer um guia destes, que falha em pontos críticos, é falta de cuidado.

Eu já li muitos documentos do Patterns and Practices, e no passado os lia como se fossem palavras sagradas (daí também o termo evangelismo). Muita gente vai ler estes documentos assim. Não vai processar, vai seguir e acabou.

Da mesma forma eu também já vi muitas aplicações feitas assim. Querem saber? Depois de algum tempo o que você encontra, na maioria dos casos, é o conhecido “smelly code”, o que em português seria um “código fedido”. A aplicação, conforme cresce, fica cada vez mais difícil de manter, às vezes a ponto de impactar até o release 1. É o típico caso de aplicação que vai morrer e ser refeita várias vezes pela mesma empresa, sob qualquer pretexto, menos que o código é fedido. Geralmente é “atualização tecnológica”, ou performance, ou qualquer outro.

Para mim isso significa mais consultoria. Mas sinceramente, eu prefero ajudar as empresas a ir mais longe, a ter que reensinar a dar os primeiros passos. Infelizmente, faço mais do segundo do que do primeiro.

Sugestão minha: leia o blog do Greg Young, que foi nomeado pela Microsoft como MVP, e portanto é reconhecido por ela como um profissional que sabe o que está falando, e pule estas recomendações do P&P. (Não todas, só essas.) E não siga nada do que leu, mas processe, entenda, e siga só o que te fizer sentido. Incluindo o que estou falando agora, aqui.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.