Não, a interrogação não é sobre se existe vida fora da sua área de discagem… A pergunta é se é possível viver sem usar Domain Driven Development.
Hoje em dia parece-me que muita gente tem a sensação de que se não estiver usando DDD não sabe programar. Ou que, se não usar todas os conceitos/padrões do DDD certinho não é filho de boa gente.
Sendo que o DDD não é nada mais que um novo nome para Orientação a Objetos feita com responsabilidade e qualidade, não me parece que seja certo achar que DDD é a pedra filosofal. Afinal Orientação a Objetos feita com responsabilidade e qualidade é que é a pedra filosofal que pode transforma a sua aplicação de coisas sem valor, num software de primeira linha.
Desde cedo criei uma certa aversão ao chamado “argumento de autoridade literária”. Basicamente, pessoas sem imaginação, sem cultura ou sem entendimento das questões utilizam as palavras que leram em livros – claro que retiradas do contexto – para afirmar o que elas querem. Esta técnica é muito usada pelo pessoal que vê na Biblia Sagrada a resposta para todas às questões, mas também é usada em outros meios. No meio científico, por exemplo, se você não tem um paper sobre o assunto ou não sabe citar um, você não pode se pronunciar. Quantos avanços, na realidade, foram feitos exactamente por aqueles que não citaram papers de ninguém (como poderiam? – era um assunto novo!).
Nas filosofias de desenvolvimento (e existem muitas, talvez demais: TDD, DDD, FDD, BDD, MDD,…) escolheu-se pegar um item necessário ao processo de desenvolvimento , endeusá-lo e fazer tudo girar à volta disso. Em TDD são os testes, em FDD as features, em MDD o modelo, em BDD o comportamento, em DDD o Domínio.
Isso é tudo muito bom até você entender que, na realidade, não faz sentido usar cada um por si. Em um projeto real você precisa de tudo: modelo, domínio, testes, modelo, features, comportamento,… Bom, mas isso é o velho e bom OO que já conhecíamos. Conhecíamos mesmos? Se conhecíamos como é que nos deixamos levar nessas ondas de *DD ?
O que o DDD tem afinal de tão diferente? A resposta é simples: publicidade. Aliás, como a maioria dos *DD e outras filosofias atuais, é apenas um apanhado de melhores práticas já previamente existentes “vendidas” como algo novo que pode salvá-lo da forca. Muda-se um nome ou outro, se esclarece um conceito ou outro, simplificam-se alguns passos e fica tudo bem simples para poder ser explicado em palestras rápidas sobre o assunto de forma que as pessoas achem que aprenderam algo diferente daquilo que sabiam
A verdade é que se você aprender OO como deve ser. Souber usar herança, polimorfismo, modificadores de acesso, e aplicar o Princípio de Separação de Responsabilidade (SoC), e tiver alguma experiência, consegue sozinho chegar nas mesmas conclusões. Padrões de projeto são por definição coisas que se repetem. Lá pela segunda ou terceira vez você vai identificar o padrão, mesmo que não saiba como ele se chama.
O conceito que a DDD lança na mesa (e diz que é novo e sagrado) é um tal de Ubiquous Language (literalmente: “Linguagem Ubiqua”, que significa “linguagem que está presente em todos os lugares”, omnipresente) que basciamente significa que todas as pessoas envolvidas no projeto, desde desenvolvedores a clientes devem usar as mesmas palavras para se referirem aos mesmos conceitos. Isto é tão obvio que dói criar um nome para isso. É uma simples regra de comunicação que se aprender na sexta série , sei lá … Só é possivel comunicar quando o símbolos (palavras) significam o mesmo para todos os intervenientes na comunicação. Protocolos fazem uso desta regra desde sempre. As próprias línguas usam esta regra. Não é nada de novo. O novo é chamar a atenção para a importância disso.
Todos os *DD elevam alguma característica do desenvolvimento ou alguma artefato ou ambos a um estatuto maior (testes, domínio, linguagem, modelo, etc…) e por isso parece que ninguém usava isso antes. Por outro lado os *DD têm a sua própria filosofia para o uso desses artefacos/idéias que já existem, mas que, se não forem usados como a filosofia requer, o resultado será desastroso (mais ou menos como ” se você não seguir a palavra de Deus, o mundo acaba” ). Então, TDD requer que se use testes automáticos (que já existiam antes) acima de todo o resto (ou melhor, antes de todo o resto), MDD requer que se tenha um modelo hiper completo que a partir dele possa ser gerado código automaticamente, e DDD requer que se defina o Domínio. Sendo que o domínio é um conjunto de conceitos que o cliente conhece, é preciso capturar esses conceitos e comunicar com o cliente nessa linguagem “de domínio”, a que o DDD batizou de linguagem ubiqua.
O TDD não suporta o uso de desenvolvimento sem testes, e o MDD não suporta sem modelo, o DDD não suporta nada além do domínio, assim vai. Na realidade você precisa de todos para que o projeto flua.
Você precisa do dominio para levantar do cliente o que aplicação deve fazer, mas ha mais coisas além do dominio. Vc precisa de features (FDD) porque existem dois tipos – funcionais e não funcionais – e o dominio só cobre as primeiras. Mas juntar tudo vc precisa de um modelo, mas não tão completo ao ponto do codigo ser gerado magicamente. Afinal desenvolvedores tb programam… vc precisa de testes para saber se está tudo em ordem … e assim vai. Vc precisa de todas as partes. Cada uma é mais util para um certo fim, mas cada uma sozinha, não leva ao sistema completo.
Bom, então, existe vida além do DDD? sim, há um monte de outros *DD por aí, mas menhum é suficiente. É preciso usar todos em conjunto, ou seja, as melhores práticas de cada um. Entretanto, note-se que as melhores práticas de cada um, são as melhores práticas de desenvolvimento orientado a objetos (OOD).
Em outro prato da balança temos os padrões de projeto referidos em literatura do DDD. Todos existiam antes do DDD ser criado. Talvez alguns ainda não tinham sido “batizados” ou simplesmente eram derivações de alguns outros que já existiam, mas não há nenhuma criação do zero aí. A criação é o isolamento e delimitação, e em última análise, a definição do domínio, através do uso desses padrões.
Quando falo que não é possível fazer DDD sem, digamos, um Repositório, alguns acham isso um absurdo, afinal o “domínio” não é um objeto e o mais importante na DDD é a linguagem ubiqua e não os objetos ou a sua implementação (afinal DDD é uma filosofia, não uma prática, as implementações dos objetos no código não importam nada, SoC não importa nada, etc.. absurdo). Mas sem o repositório, como eu isolo o domínio de, por exemplo, a infraestrutura? A resposta é: não isolo. Se fosse possível, o Repositório não seria mencionado na literatura (dah!). E eu quero isolar? sim. Sem o isolamento não há uma representação do domínio no código o que viola o próprio conceito de Domain Driven e o conceito de linguagem ubiqua, já que os conceitos estão em todo o lugar exceto no código. O exemplo simples é o famoso DAO. Você vai explicar o que é um DAO para o cliente? Ele vai lhe pedir que implemente um DAO? Não. Então um DAO não é um objeto do domínio. O cliente vai apresentar o conceito de “lugar onde as entidades estão”. normalmente a frase usada refere-se a banco de dados porque o cliente acha que é essa a representação do conceito de “lugar onde as entidades estão”. Ele fala: “então aí, depois de ter feito essa conta, você salva no banco”. O que ele quer dizer é “depois de ter feito a conta você guarda no lugar onde as entidades estão“. Este conceito é usada ad naseum e portanto é necessário arranjar um nome para ele (seguindo a permissa da linguagem ubiqua). Então chamamos-lhe Repositório. Algumas vezes o cliente vai dizer “então, você pega do banco todos os produtos dessa marca e mostra na tela com um sistema de navegação paginado” o que ele quer dizer é “então, você pega do repositório todos os produtos dessa marca”. Se o repositório é um banco de dados ou não, na verdade não interessa ao cliente. Se interessar isso é um requisito não-funcional porque a implementação do repositório não altera a funcionalidade do domínio.
Bom, mas podemos chegar no conceito de repositório de outra forma. De uma forma OOD.
É comum que o sistema faça pesquisas por dados. O SoC exige que apenas um objeto saiba onde esses dados realmente estão e que um objeto seja responsável por montar as pesquisas. Do ponto de vista dos outros objetos, ele chamarão o objeto que faz as pesquisas e esse invocará o objeto que sabe onde os objetos estão. Do ponto de vista exterior, apenas existe o objeto que faz as pesquisas, já que o outro não pertence à mesma camada (pertence a uma camada inferior), portanto, para a camada que quer os objetos, tudo se passa como se os objetos estivessem contidos dentro do objeto que faz as pesquisas e retornas os objetos. Por coerência esse objeto é chamado de Repositório. Este é o padrão proposto fora do DDD por Martin Fowler e depois recauchutado para o conceito de Repositório usando na literatura do DDD (como disse, nada foi criado).
A conclusão é que, seguindo apenas um desenvolvimento OO simples, sem utilizar as filosofias especiais do DDD, chegariamos na mesma conclusão. Talvez não tão depressa, mas chegaríamos. Isto é óbvio, porque OO é uma teoria fechada, não ha como inventar nada fora dela sem a alterar.
Bom, então existe vida fora do DDD ? Sim, existe o desenvolvimento orientado a objetos.
Como todo o desenvolvimento ele está vigiado por testes, montado em cima de modelos, deve prover features, e valor para o cliente/ usuário do software. Além disso deve prover qualidade e fácil manutenção para outros desenvolvedores. Nada de novo aqui (!).
Então a minha sugestão é que não se perca em *DD antes de ter uma muito boa base em desenvolvimento orientado a objetos e em desenvolvimento per se. Se sentir-se tentado a dar uma espiada, ótimo, mas tenha em mente que não existe nenhuma revelação exotérica nessas filosofias.
Menos conversa e melhor modelagem OO. É só isso que é preciso.
