Influências de Domain-Driven Design

Nos últimos anos a prática de Domain-Driven Design vêm ganhando popularidade. Mesmo não sendo amplamente aplicada, muitas de suas abordagens influenciam o desenvolvimento de softwares como um todo.

Para quem não está familiarizado com o tema, DDD é uma abordagem para desenvolvimento de software. Esse termo for criado por Eric Evans no livro Domain-driven design: tackling complexity in the heart of software.

De uma maneira super resumida, DDD visa eliminar as diferenças entre negócio e software, o software deve espelhar exatamente o domínio sendo tratado. Para tanto, são adotadas diversas práticas no desenvolvimento, como por exemplo: colaboração mais próxima do especialista no negócio, uso de uma linguagem única pelos desenvolvedores e especialistas, e deixar os conceitos envolvidos na aplicação explícitos.

Como o próprio Eric Evans deixa claro, DDD não é uma abordagem a ser adotada no desenvolvimento de qualquer software, ela deve ser adotada apenas em sistemas complexos.

Mesmo não adotando a abordagem como um todo, podemos tirar proveito de diversas práticas no desenvolvimento de qualquer software.

Deixando os conceitos explícitos

Uma das práticas de DDD é deixar os conceitos explícitos. Ou seja, deixar clara a intenção deles. Isso deve ser feito tanto no nível de código como na própria interface.

Um exemplo que me deparei recentemente onde os conceitos não estão muito claros é no Blogger. Ao editar uma postagem vemos uma tela semelhante a figura abaixo:

A questão nessa tela são os botões “Publicar postagem” e “Salvar”. As ações deles não ficam muito claras ao usuário. Enquanto criamos uma postagem eles tem as funções de:

• Publicar postagem – tira a mensagem dos rascunhos e publica oficialmente a mensagem;
• Salvar – simplesmente atualiza os dados da postagem;

Se a mensagem já foi publicada, as funções são:

• Publicar postagem – simplesmente atualiza os dados da postagem;
• Salvar – move para os rascunhos a mensagem já publicada;

Ficaria muito mais claro para o usuário se as funções de Publicar, Mover para rascunhos e Salvar fossem distintas. Na minha opinião, ficaria muito mais claro com as seguintes opções:

• Salvar – simplesmente atualiza os dados. Não move para rascunhos e não publica, atualiza os dados independente do estado da postagem;
• Publicar postagem – aparece apenas se a postagem ainda não foi publicada;
• Mover para rascunhos – cancela a publicação e coloca novamente a mensagem nos rascunhos.

É uma alteração simples e que envolve basicamente renomear os botões. Pode ser que eu seja chato, mas acho que dessa forma fica muito mais claro para o usuário qual o efeito de cada comando.

Utilizando técnicas de DDD no dia-a-dia

Como já mencionei antes, DDD não é uma abordagem a ser adotada em todo e qualquer software, porém podemos tirar lições dela e adotar algumas partes no desenvolvimento do dia-a-dia. Sempre que possível podemos deixar os conceitos mais explícitos e usar nomenclaturas padronizadas. Ou seja, deixar claro tanto para o desenvolvedor como para o usuário o efeito de cada ação e sua relação com o negócio.