Movimentos estratégicos: explorando o tabuleiro de xadrez do Domain-Driven Design

Felipe Windmoller, com mais de 20 anos de experiência em TI, é especialista no Banco do Brasil, com foco em mainframe, cloud, microsserviços, integração, DDD, SRE e observabilidade.

Desenvolvimento de software e um jogo de xadrez. À primeira vista, pode não ser óbvio comparar esses dois assuntos, e eles podem parecer fundamentalmente diferentes para você; no entanto, esses dois tópicos baseiam-se em percorrer uma abundância de possibilidades e escolhas e têm mais semelhanças do que você poderia imaginar.

Neste artigo, apresentarei os princípios estratégicos e táticos do Domain-Driven Design (DDD), comparando-os às estratégias e táticas de uma partida de xadrez.

Estratégias no xadrez

O objetivo do xadrez é muito claro: queremos ganhar o jogo! No entanto, isso é um desafio. Imaginemos o início de uma partida: cada peão pode mover uma ou duas casas, e cada cavalo também pode fazer dois movimentos diferentes. Portanto, existem vinte opções diferentes para fazer o primeiro movimento de xadrez. Para complicar ainda mais as coisas, depois do nosso primeiro movimento, é a vez do nosso adversário, e então devemos tomar uma nova decisão. O número de possibilidades aumenta exponencialmente à medida que tentamos calcular os movimentos que podem ser feitos, dependendo da decisão do nosso adversário. Alguns grandes mestres têm a reputação de prever de 15 a 20 movimentos.

Então como sabemos qual é um bom movimento de abertura? A estratégia do xadrez pode nos guiar. O jogo é dividido em três fases: abertura, meio e fim. Na abertura, devemos seguir estes princípios: controlar o centro do tabuleiro, desenvolver nossas peças menores (cavalos e bispos) fazer o roque para proteger o nosso rei e mover a nossa dama para conectar as nossas torres. Após cumprir esses princípios, finalizamos a fase inicial e entramos no meio da partida. Estudos provaram que seguir esses princípios aumenta as nossas chances de ganhar o jogo.

Tendo a estratégia de abertura esclarecida, parece mais fácil escolher o nosso primeiro movimento. Por exemplo, podemos mover nosso peão da rainha para d4, e ele parece perfeito de acordo com os princípios estratégicos e atende a dois objetivos estratégicos. Primeiro, o peão agora está em posição de controlar as casas c5 e e5 e, portanto, estamos no centro do tabuleiro e um passo mais perto de controlá-lo. Em segundo lugar, dá espaço para o nosso bispo e rainha se moverem.

Estratégia e heurística

Como afirmado anteriormente, o número de movimentos possíveis num jogo de xadrez pode ser esmagador, e a estratégia nos ajuda a encontrar movimentos melhores e mais rápidos. A técnica mental de tomar atalhos para resolver problemas complexos rapidamente é chamada de heurística. Ela nos fornece resultados bons o suficiente para nossos objetivos imediatos. Isso é útil quando precisamos tomar uma decisão, mas demoraríamos muito tempo analisando todas as informações e possibilidades. Trazendo isso para a nossa discussão aqui, imagine que é a sua vez de fazer uma jogada e existem cerca de 20 possibilidades diferentes, porém agora você sabe que existem estratégias que pode seguir e reduzir esse número para 5. A ideia é que a heurística ajudaria você escolher dentro dessas 5 possibilidades, possibilitando que você faça uma boa jogada – não necessariamente a melhor, mas mais rápida, já que você teria menos opções.

Estratégias do Domain-Driven Design

Já foi dito que o objetivo de um jogo de xadrez é vencer. Em comparação, qual é o nosso objetivo em um projeto de TI? A resposta mais simples é que devemos resolver um problema de negócios com uma solução de software. Portanto, o elemento mais importante em um projeto de software é entender o problema, pois, por melhor que seja a nossa implementação, se não entendermos os requisitos de negócio, será impossível atingir o nosso propósito.

Além disso, como no xadrez, no mundo da TI também estamos sobrecarregados de informações e possibilidades diversas. Por exemplo: como avaliamos nossas opções e escolhemos a melhor para construir um software que atenda ao problema do negócio? Dependendo da complexidade do domínio, o número de opções é enorme, e é difícil tomar uma decisão.

Domain-Driven Design (DDD) é uma técnica criada por Eric Evans em 2003 para melhorar a comunicação entre a área de negócio e a de TI e nos dar heurísticas para decidir a melhor implementação de software. Da mesma forma que a estratégia do xadrez nos ajuda a escolher que peça devemos mover para iniciar o jogo, as estratégias do DDD nos ajudam a fazer escolhas para construir um software que atenda às necessidades do negócio.

As estratégias, simplificando, consistem em identificar o domínio de negócio e seus subdomínios, construir a linguagem ubíqua e modelar os contextos delimitados. Devemos primeiro entender esses conceitos e depois ver como eles podem nos ajudar a construir projetos de software.

Domínio de negócio e subdomínios

O domínio de negócio é o mercado em que uma empresa está inserida, como investimentos, cartão de crédito, marketing. Ele está dividido em subdomínios, que são os blocos de construção do negócio que trabalham em conjunto e permitem a existência da empresa. Tomemos como exemplo uma empresa de varejo. Alguns subdomínios podem ser clientes, contabilidade e estoque.

Existem três tipos de subdomínios: core, genérico e de suporte. Os subdomínios core são importantes porque diferenciam uma empresa das outras e é o que torna a empresa especial e bem-sucedida. São complexos e estão sempre mudando para gerar melhorias.

Os subdomínios de suporte são simples, não mudam muito e não provêm um diferencial competitivo para a empresa. No entanto, devemos construí-los nós mesmos, porque não existem soluções pré-fabricadas disponíveis ou porque é apenas mais fácil desenvolvê-los do que implementar uma integração com uma solução já pronta.

Os subdomínios genéricos são complexos, mas não únicos e, portanto, não tornam a empresa especial. São problemas que já foram resolvidos antes, até mesmo por outras indústrias, e existem soluções que podemos usar, como softwares que você pode comprar ou usar gratuitamente. Por exemplo, pense na criptografia: a menos que este seja o negócio principal da empresa, é mais inteligente usar algo que já foi feito em vez de desenvolvê-lo do zero.

No xadrez nos perguntamos qual peça devemos mover primeiro. Num projeto de software, perguntamos que tipo de arquitetura devemos usar. Talvez arquitetura em camadas? Arquitetura hexagonal? Segregação de responsabilidade de comando e consulta (command and query responsibility segregation – CQRS)? O DDD estratégico nos dá algumas heurísticas para decidir. Dependendo do tipo de subdomínio, podemos escolher a melhor arquitetura. Para um subdomínio de suporte simples, podemos optar pela arquitetura em camadas, mas para um subdomínio core, que é complexo e muda frequentemente, a arquitetura hexagonal pode ser uma opção melhor.

Linguagem ubíqua e contextos delimitados

Conforme mencionado anteriormente, a comunicação entre a área de negócio e a TI é um desafio. Frequentemente, existem duas linguagens distintas: uma compreendida por especialistas no domínio de negócio e outra usada por programadores de software. Esse problema aumenta a carga cognitiva das equipes e incrementa a probabilidade de mal-entendidos. É um pouco como o jogo do telefone sem fio que as crianças jogam. Os requisitos das áreas de negócio precisam ir do domínio da linguagem que os especialistas de negócio usam até aquele que os programadores entendem e, frequentemente, essa tradução está longe de ser perfeita.

A estratégia proposta pelo Domain-Driven Design para resolver esse problema de comunicação é adotar a mesma terminologia usada pelos especialistas de negócio em todos os aspectos de um projeto de software. Isso significa que os mesmos termos usados nas reuniões entre os especialistas do domínio de negócio e os times de TI aparecerão em modelos, tabelas e programas. É por isso que o nome desse padrão é linguagem ubíqua, que é uma linguagem única usada em todos os lugares para manter as coisas claras e consistentes.

Porém, quando as pessoas falam, algumas palavras podem ter significados diferentes dependendo da situação. Por exemplo, num contexto de vendas, “cliente” pode referir-se a alguém que compra bens, enquanto num contexto de suporte pode referir-se a alguém que procura assistência. Essa dúvida não é problema para conversas humanas, mas os programas de software não admitem ambiguidades, tudo deve ter uma definição clara.

Para superar esse problema, o DDD estratégico possui um padrão chamado de “contexto delimitado”. A ideia é exatamente como o nome sugere: delimitamos um contexto ao significado dos nossos termos. No nosso exemplo anterior do termo “cliente”, teríamos um contexto delimitado denominado “vendas” e outro denominado “suporte”. Portanto, dentro do contexto delimitado de “vendas”, a palavra “cliente” terá exatamente um significado.

Microsserviços e Domain-Driven Design

Em uma arquitetura de microsserviços, definir corretamente o tamanho dos nossos serviços é muito importante. Se forem muito grandes, tornam-se individualmente muito complexos e difíceis de manter. Por outro lado, se forem demasiadamente pequenos, a complexidade global de muitos microsserviços minúsculos comunicando-se entre eles será elevada. O DDD nos ajuda com algumas heurísticas: um microsserviço não deve ser maior que um contexto delimitado, ou então a nossa linguagem não será clara, e o software poderá ficar muito complicado. Normalmente, o tamanho de um microsserviço se adapta bem a um subdomínio. As fronteiras do tamanho do aplicativo estarão em harmonia com o funcionamento do domínio de negócio, e as novas demandas de mudanças no sistema normalmente serão direcionadas a um único microsserviço, sem causar um efeito cascata em que vários microsserviços precisarão ser alterados e implantados juntos.

Estratégias e táticas

As estratégias servem como princípios orientadores que nos guiam para as melhores escolhas, oferecendo um roteiro para atingirmos objetivos globais. Seja com o propósito de triunfar em uma partida de xadrez ou de ter êxito em um projeto de software, as estratégias traçam a trajetória para o sucesso a longo prazo. Em contraste, as táticas nos direcionam a resultados rápidos. Elas se concentram em realizar ações em um curto espaço de tempo.

Táticas do xadrez

As táticas de xadrez são truques inteligentes que os jogadores usam para pegar seus oponentes desprevenidos ou vencer rapidamente. Uma tática famosa é o ataque duplo. Isso acontece quando um único movimento cria dois problemas para o oponente, e ele não consegue se defender de ambos. Veja a imagem abaixo: o cavalo está atacando o rei e a torre ao mesmo tempo. O adversário deve mover o rei e, no turno seguinte, perderá a torre.

Táticas do Domain-Driven Design

Embora o DDD estratégico nos forneça uma orientação para compreender os requisitos de negócios e criar soluções de software alinhadas com os objetivos da empresa, o Domain-Driven Design tático opera dentro do domínio prático da codificação dos programas. Os três padrões táticos mais reconhecidos do DDD são value objects (objetos de valor), entidades e agregados.

Value objects são componentes importantes na programação que nos ajudam a representar informações específicas, como datas ou valores monetários, de forma clara e consistente. Eles são como pequenos contêineres para dados e regras que tornam nosso código mais fácil de entender e manter. Os value objects são especiais porque, uma vez criados, não podemos alterá-los, o que mantém nossos dados confiáveis. Eles são como blocos de construção que nos ajudam a criar um software resiliente e confiável. Value objects podem ser identificados pela composição de seus valores.

As entidades são essenciais na programação, pois representam os elementos centrais de um sistema que possui identidades e comportamentos únicos. Assim como os personagens de uma história, as entidades contêm informações importantes e podem interagir umas com as outras. Esses objetos nos ajudam a modelar conceitos do mundo real, como clientes ou pedidos. Como as entidades têm identidades individuais, elas são cruciais para rastrear e gerenciar os dados com precisão. Na programação, as entidades atuam como os personagens principais que impulsionam nossas aplicações.

Os agregados são vitais na programação porque agrupam entidades relacionadas e value objects, criando uma estrutura mais organizada para o nosso código. Pense neles como contêineres que agregam tudo o que é necessário para lidar com uma parte específica do nosso sistema. Os agregados nos ajudam a gerenciar dados e interações complexas, fornecendo limites claros para as operações. Isso torna nosso código mais compreensível e reduz as chances de erros. Na programação, os agregados atuam como guardiões da consistência e integridade, garantindo que nossos dados permaneçam precisos e confiáveis.

Palavras finais

Para finalizar, tanto a estratégia do DDD quanto a estratégia do xadrez guiam nossas escolhas. Imagine a estratégia como um grande plano para o longo prazo e as táticas como etapas práticas para o momento. É como ter um mapa para a jornada e ferramentas para a aventura. Apesar das diferenças entre xadrez e TI, ambos compartilham um objetivo em comum: o desejo de sucesso. No xadrez o nosso objetivo é vencer a partida; na TI nos esforçamos para ter sucesso em nossos projetos.