Domain-driven design (DDD) tem performance para sistemas de tempo real?

Para sistemas de informação convencionais, nunca vi como preocupante certos problemas (toleráveis) de performance. Mas outro dia assisti a uma entrevista muito legal de 2008, tratando sobre o tema.

Nela, Eric Evans, autor do Livro Domain-driven Design, entrevistou um desenvolvedor fundador de uma  empresa do mercado de ações. Eles construíram um sistema para receber e para processar ordens de compra/venda, fazer análise, automatizar ordens, etc., utilizando DDD e ainda assim apresentando altíssima performance, sendo capaz de processar dezenas de milhares de requisições por segundo.

Uma das estratégias deles foi distribuir o processamento dividindo o domínio em diversos servidores, baseado nas “Aggregate Roots” (conceito do DDD). Logo, cada instância da entidade Empresa (Google, Yahoo, etc.), por exemplo, que é uma Aggregate Root, é gerenciada por um servidor distinto.

Também mudaram um pouco a forma como os repositórios recebem as alterações de dados. Ao invés de receber entidades inteiras no novo estado para salvar, eles recebem objetos que representam as alterações de estado das entidades.

Além disso, permitem salvamentos em ordem aleatória, permitindo que o sistema tenha seus dados ligeiramente inconsistentes em certos momentos, enquanto parte das alterações ainda não foram salvas.

Enfim, o legal disso tudo é que frequentemente assumimos que desenvolver com tantas camadas de abstração, como no caso do DDD, não é muito viável para sistemas de missão crítica, onde performance seja extremamente importante. Contudo, isso só ocorre quando conduzimos implementações ingênuas, que até serviam para  realidades mais “leves”, mas não atendem ao novo cenário mais extremado.

A minha conclusão é que, no final das contas, é a nossa capacidade de projetar soluções inteligentes que fará a diferença na performance, e não o fato de utilizarmos arquiteturas mais desacopladas ou não.

E você, o que acha?