Como um Modelo de Domínio pode alavancar o seu projeto de software

Escrever software é uma das atividades humanas mais complexas que existe. E isso se deve em grande parte às etapas envolvidas durante o processo de concepção e implementação, onde basicamente precisamos abstrair atividades do mundo real em uma linguagem puramente lógica. Com isso, fica fácil observar a importância de um bom planejamento e levantamento de requisitos no projeto de software.

Além do início de um novo projeto, esses processos de idealização também acontecem antes de desenvolvermos novas funcionalidades para uma aplicação em produção. Isso nos mostra o quanto a nossa capacidade de assimilação de conhecimento é necessária para um bom projeto de software. Além disso, esta dinâmica de análise-concepção-implementação influencia no quanto um produto de software gera valor aos seus usuários.

Muitas e muitas falhas referem-se a aspectos que nunca chegaram a ser bem especificados. — Vyssotsky, Head do projeto Multics

Sabemos então que produzir software é lidar com a complexidade. Entretanto, ao contrário do que podemos imaginar, quando essa atividade é bem executada, ela pode se tornar prazerosa e recompensadora.

Brooks em The Mythical Man-Month afirma que a arte da programação “gratifica anseios criativos construídos profundamente dentro de nós e deleita sensibilidades que temos em comum com todos os homens”, fornecendo, ainda, cinco tipos de alegrias:

• A satisfação de construir algo;
• A felicidade de se construir algo útil para os outros;
• O fascínio da montagem de objetos complexos, como em um quebra-cabeça com peças móveis que se interconectam;
• A alegria da aprendizagem constante, que vem da natureza não-repetitiva da tarefa;
• A delícia de se trabalhar em um meio tão maleável — pura matéria de pensamento — que ainda assim existe, movimenta-se e funciona de uma maneira impossível para palavras simplesmente escritas.

Mas para que possamos atingir esse nível de satisfação ao se trabalhar com software, é preciso termos um arcabouço de ferramentas conceituais que nos guiarão em direção a um software sustentável. E é aqui que nos deparamos com o Modelo de Domínio, um conceito bastante discutido por Eric Evans em seu livro Domain-Driven Design e, apesar de fazer parte dos pilares do DDD, transpõe os seus limites, podendo ser considerado um princípio de design universal.

Neste artigo iremos explorar o conceito de Modelo de Domínio e como ele pode nos ajudar a alavancar os nossos projetos de software, com códigos fáceis de dar manutenção, redução de custos de desenvolvimento, operações que revelam intenções de negócio e, acima de tudo, entregar valor aos seus usuários. Portanto, iremos discorrer sobre:

• O que é um Modelo de Domínio
• O Modelo como pilar da comunicação
• Construindo um Modelo de Domínio compartilhado
• Ligando a implementação ao Modelo

O que é um Modelo de Domínio

Ao pesquisar no dicionário pela palavra modelo é encontrado a seguinte definição:

Representação em escala reduzida de objeto ou obra arquitetônica.

Em outras palavras, um modelo simplifica um objeto do mundo real, excluindo partes que não interessam para o propósito daquele modelo. Um exemplo é um modelo matemático, que pode ser a representação matemática de um fenômeno físico natural, feito para que se possa melhor estudar o original.

Um Modelo de Domínio, portanto, é uma representação simplificada e objetiva de uma atividade empreendida por uma empresa, pessoa ou coisa.

O domínio de um restaurante, por exemplo, pode envolver a produção e apresentação dos pratos, os ingredientes usados e/ou modo de preparo.

Um modelo é uma simplificação. Ele é uma interpretação da realidade que destaca os aspectos relevantes para resolver o problema que se tem em mãos, ignorando os detalhes estranhos. — Eric Evans

Alguns domínios possuem uma quantidade intimidante de informação que dificulta o projeto de software. Essa sobrecarga de elementos conceituais precisa ser assimilada pelos projetistas a fim de produzir um software útil aos seus usuários. Uma tarefa nada trivial que quando mal feita pode gerar um produto defeituoso que não atende as expectativas dos stakeholders.

Um Modelo de Domínio cuidadosamente concebido é capaz de atacar essa sobrecarga de informação, abstraindo todos os conceitos envolvidos e guiando o entendimento e comunicação das equipes durante o projeto. Com um Modelo de Domínio compartilhado, todos falam o mesmo idioma, se concentram no principal problema a ser resolvido, se esquivam de erros de design e a implementação do software é clara e precisa.

Um modelo é uma forma de conhecimento seletivamente simplificada e conscientemente estruturada.

Faz-se importante ressaltar que um diagrama não é o Modelo do Domínio. Ele ajuda a representar e comunicar o modelo, assim como um código bem escrito ou assim como uma frase em português. Concluímos, então, que o modelo é um artefato abstrato que permeia todas as atividades envolvidas no projeto de software.

O Modelo como pilar da comunicação

É bastante comum termos, numa primeira etapa, equipes de negócios pensando nas soluções que um aplicativo pode entregar aos seus usuários e, numa segunda etapa, as equipes de tecnologia decidindo sobre a modelagem e arquitetura da solução. Temos aqui duas dinâmicas intimamente relacionadas que possuem o mesmo objetivo: abstrair uma situação real numa solução de software.

Normalmente essa situação produz múltiplos artefatos com linguagens e abordagens diferentes. Ou seja, não há uma modelagem compartilhada entre as equipes. Ou o documento é muito técnico —afastando o time de negócios — , ou é muito distante de um design técnico — impossibilitando o uso do documento como um guia de desenvolvimento do software.

Esse é um problema latente que obscurece o conhecimento da equipe técnica em relação ao domínio. Ao invés de serem guiados por um modelo sofisticado, se orientam por diagramas técnicos de bancos de dados, utilizando termos do design técnico para descrever conceitos reais de domínio. O resultado é um software escrito mecanicamente, com problemas de design e que dificultará as refatorações à medida que o software é construído.

Além de afetar o time técnico, a falta de um modelo dificulta as reuniões com os times de negócio e o planejamento e levantamento de requisitos. As implicações disso são palavras ambíguas durante conversas, conceitos de domínio mal interpretados, entregas atrasadas, tarefas que se extendem por várias sprints etc.

Percebemos então que um Modelo de Domínio é a base da comunicação entre os times.

Use o modelo como a espinha dorsal da linguagem. Se ainda não existir um modelo com o qual se apoiar, as discussões deverão guiar a busca por um modelo compartilhado, refinando-o a cada iteração. — Eric Evans

Com essa aproximação entre modelo e linguagem ganhamos um idioma único que é usado por todos os times. Ao utilizar essa linguagem onipresente, as discussões se tornam fonte de conhecimento. Assim, toda reunião com o time de negócios se torna uma oportunidade de destilar o Modelo do Domínio. Em outras palavras, muitas das frases produzidas nesas seções de conversa podem ser descritas em termos de relações e interações no modelo. Ademais, os especialistas podem utilizar a linguagem do modelo ao escrever casos de uso e testes de aceitação.

Além de melhorar a comunicação, o Modelo de Domínio compartilhado é capaz de guiar a implementação do software. Os projetistas podem se valer de diagramas que representam o modelo e usá-los nas discussões com os especialistas do negócio. Nesse sentido, percebemos que o time de negócio passa a fazer parte da concepção do software, interagindo com o time técnico em busca de melhor representar o modelo no código.

Construindo um Modelo de Domínio compartilhado

Um Modelo de Domínio é construído através de interações ricas entre o time de negócios e o time técnico. Quando o objetivo da reunião é discutir sobre um novo projeto, é muito provável que ainda não exista um modelo com o qual se apoiar. Assim, é extremamente importante que as discussões guiem a busca por um modelo. Por outro lado, quando o objetivo da reunião é discutir sobre uma funcionalidade, é bastante provável que já exista um modelo. Mais uma vez, se ainda não existir, os times devem construir um.

Entretanto, a construção do modelo nunca termina. Como eu já disse acima, cada reunião é uma oportunidade de destilar o modelo. Torná-lo melhor. Isso se deve ao fato de que a necessidade real de um software nunca é clara até que os usuários a utilizem. Em The Mythical Man-Month Brooks enfatiza essa ideia ao dizer que “tanto a necessidade real quanto a percepção do usuário relativa a essa necessidade mudarão enquanto os programas são construídos, testados e utilizados.”.

O modelo se torna rico e valioso na medida em que o software passa por ciclos de feedbacks e experimenta novas abstrações. As conversas cada vez mais profundas com os especialistas do domínio começam a revelar conceitos ocultos e refatorações são feitas para ajustar o código à essa nova visão do modelo.

Esse tipo de assimilação do conhecimento transforma o conhecimento da equipe em modelos valiosos.

Essa destilação do Modelo de Domínio pode acontecer com o apoio de algumas ferramentas de projeto. Os desenvolvedores são livres para usar diagramas que se aproximam (mas não usam) a notação UML para guiar a modelagem junto aos especialistas. Sabendo que o Modelo de Domínio guia o design do software, é perfeitamente aceitável utilizar esses diagramas para descrever conceitos e relações de objetos de domínio.

Assim, na medida em que os times assimilam o conhecimento do domínio, eles são capazes de explorar opções de modelo, refiná-las e transformá-las em elementos práticos do software. Esse é um processo iterativo de refinamento não só do modelo, mas do design e do código.

Os desenvolvedores e especialistas do domínio podem informalmente testar o modelo caminhando pelos cenários, usando os objetos do modelo passo a passo. Praticamente todas as discussões são uma oportunidade para que a equipe possa juntos brincar com o modelo, aprofundando o entendimento de cada um e refinando os conceitos durante o processo. — Eric Evans

Vale lembrar que o diagrama não é o modelo e deve atender duas finalidades: expressar fielmente os conceitos fundamentais do domínio e possibilitar a implementação do software. Como resultado, se o time de negócios não entender o modelo, podemos concluir que há algo de errado com o modelo.

Ligando a implementação ao Modelo

Quando orientamos o nosso projeto através de um Modelo de Domínio descartamos a dicotomia de um modelo de análise (time de negócios) e um modelo de design (time técnico). Por conseguinte, passamos a ter um modelo único que atende as duas finalidades. A junção desses dois mundos resulta em objetos de design que deixa de lado questões puramente técnicas, ao passo que desempenha um papel conceitual descrito no modelo.

Quando bem implementado, o código se torna uma expressão do domínio. Seus objetos, funções e módulos são enriquecidos pela linguagem onipresente. O código é tão ligado ao modelo que uma mudança no código implica uma mudança no modelo.

Novos desenvolvedores que integram o time aprendem sobre o modelo a medida que lê o código. Sua fala rapidamente é suplantada por termos do domínio e a conversa com os especialistas se torna natural.

Haja vista essa ligação entre o código e o modelo, esse último deve ser prático para implementação. Da mesma forma que devemos procurar um novo modelo quando o atual não expressa o domínio, também devemos procurar um novo se o atual não for prático para implementação.

Revise o modelo e modifique-o para que ele seja implementado de forma mais natural no software.

Diferente de uma implementação guiada por esquemas relacionais ou estruturas de dados, a implementação ligada ao Modelo de Domínio reduz os custos de desenvolvimento e manutenção, pois os erros causados pelo design são mitigados no processo de assimilação do conhecimento.

Exemplo

Neste exemplo vamos usar o domínio de transporte de carga ilustrado por Eric Evans em seu livro Domain-Driven Design. Nesse domínio, os desenvolvedores e especialistas podem começar uma discussão sobre o modelo com um diagrama bem simples:

Durante os ciclos de feedback e implementação novas abstrações podem surgir. O processo de assimilação de conhecimento e o descobrimento de novos conceitos vai enriquecendo o modelo. Assim, os blocos que antes eram bem simples, passam a ter propriedades e até comportamentos:

Repare que a construção do modelo não é algo mecânico. Essa concepção é orientada por conversas com especialistas do domínio e uso do software pelos usuários.

O domínio de transporte de cargas envolve uma imensidão de informações, sendo impraticável tentar abstrair todas elas num software. Portanto, o modelo utiliza apenas as informações que são relevantes para seu propósito, ignorando tudo aquilo que não acrescenta valor.

Conclusão

Apesar do projeto de software ser uma atividade humana complexa, é inegável a satisfação que obtemos quando desenhamos uma solução que gera valor aos seus usuários. Desenvolver software, portanto, não significa sentar, olhar os requisitos de negócio, e sair escrevendo funções à rodo. É preciso mergulhar no domínio que se pretende atender, digerir uma quantidade expressiva de informações, assimilar ideias e abstrair conceitos. Para isso ser possível, é necessário considerar um conjunto de princípios e ferramentas conceituais que guiarão o projeto do software. Certamente o Modelo de Domínio é um excelente aliado nessa jornada.

Espero que este artigo tenha sido útil para você. Fique à vontade para expressar a sua opinião ou contribuir com outras ideias sobre o Modelo de Domínio.