Felipe Windmoller, with more than 20 years of IT experience, is a specialist at Banco do Brasil, focusing on mainframe, cloud, microservices, integration, DDD, SRE and observability.

Software development and a game of chess. At first, it might not be obvious to compare these two subjects and they might seem fundamentally different for you; however, these two topics are based on navigating an abundance of possibilities and choices and have more similarities than you could anticipate. In this article, I will take you through the strategic and tactical principles of Domain-Driven Design (DDD) comparing it to strategies and tactics of a chess match.

Chess Strategy

The objective of chess is very clear: we want to win the game! However, this is challenging. Let’s imagine the beginning of a game: each Pawn can move one or two squares and each Knight can also make two different moves. So, there are twenty different options to make the first chess move. To make things more complicated, after our first move it’s our opponent’s turn and then we must come up with a new decision. The number of possibilities increases exponentially as we try to calculate the movements that can be done depending on our opponent’s decision. Some great masters are reputed to predict 15 to 20 moves ahead.

So, how do we know what is a good opening movement? Chess strategy can guide us. In the chess strategy the game is divided into three phases: opening, middle and end game. In the opening, we must follow these principles: control the center of the board, develop our minor pieces – the Knights and Bishops – castling to protect our King and move our Queen to connect our Rooks. After accomplishing these principles, we finish the opening phase and enter the middle game. Studies have proved that following these principles improve our chances of winning the game.

Having the opening strategy clarified it looks easier to choose our first move. For example, we can move our Queen Pawn to d4, and it seems perfect according to strategy principles and it meets two strategy objectives. First, the Pawn now is in position to control c5 and e5 squares and so we are in the center of the board and one step closer to get control of it. Second, it gives space for our Bishop and Queen to move.

Strategy and Heuristics

 As stated before, the number of possible moves in a chess game can be overwhelming and strategy helps us find faster and better ones. The mental technique of taking shortcuts to solve complex problems fast is called heuristic. It provides us with results that are good enough for our immediate goals. This is useful when we need to make a decision, but we would take too much time analyzing all the information and possibilities. Bringing this to our discussion here imagine it is your turn to make a move in the game and there are around 20 different possibilities, however now you know there are strategies you can follow and reduce this number to 5. The idea is that heuristic would help you choose within these 5 possibilities, making it possible for you to make a good move, not necessarily the best, but fast since you had less options.

Domain-Driven Design Strategy 

It has been said that the objective of a chess game is to win. In comparison, what is our goal in an IT project? The simplest answer is that we must resolve a business problem with a software solution. Therefore, the most important element in a software project is to understand the problem, because no matter how good our implementation is, if we don’t understand the business requirements it will be impossible to achieve our purpose.

Furthermore, as in chess, in the IT world we are also overwhelmed with information and different possibilities. For example: how do we evaluate our options and choose the best one to build a software that can suit the business problem? Depending on the domain complexity the number of options is huge and it’s difficult to make a decision.

Domain-driven design (DDD) is a technique which was created by Eric Evans in 2003 to help us improve the communication between businesspeople and IT and give us heuristics to decide the best software implementation. In the same way which chess strategy helps us choose what piece we should move to start the game, DDD strategies also help us make choices to build a software that serves the business needs.

The strategies, simplifying, are to identify the business domain and its subdomains, build the ubiquitous language and design the bounded contexts. We should first understand these concepts and then see how they can help us build software projects.

Business Domain and Subdomains 

The business domain is the market in which a company is inserted such as investments, credit card, marketing. It is divided into subdomains which are the business building blocks working together and allowing the company to exist. Let’s take a retail company for example, some subdomains could be customers, accounting, and stocking.

There are three types of subdomains: core, generic and supporting. Core subdomains are the important ones because they differentiate a company from others and it’s what makes the company special and successful. They are complex and are always changing to generate improvements.

Supporting subdomains are the simple ones, they don’t change too much and don’t make the company unique. However, we must build them ourselves because there are no pre-made solutions available, or it’s just an easier solution rather than developing the integration with a ready-made one.

Generic subdomains are complex but not unique and so they don’t make the company special. They are problems that have been solved before, even by other industries, and there are solutions out there that we can use, as software you can buy or use for free. For instance, think about encryption, unless this is the core business of the company it is smarter to use something that is already made instead of developing it from scratch.

In chess we wonder which piece we should move first. In a software project we ask what type of architecture we should use. Perhaps, layered architecture? Hexagonal architecture? Command and query responsibility segregation (CQRS)? Strategic DDD gives us some heuristics to decide. Depending on the subdomain type we can pick the best architecture. For a simple supporting subdomain, we can go with layered architecture but for a core subdomain, which is complex and changes often, hexagonal architecture could be a better option.

Ubiquitous Language and Bounded Contexts

As mentioned earlier, communication between businesspeople and IT is challenging. Often, there are two separate languages: one understood by domain experts, and another used by software programmers. This issue increases the cognitive load on teams and makes misunderstandings more likely. It’s a bit like the telephone game kids play. The requirements from businesspeople need to go from the language domain experts use to the one programmers understand, and, frequently, this translation is far from perfect.

The strategy proposed by domain-driven design to tackle this problem of communication is to adopt the same terminology used by the business specialists in everywhere in a software project. This means that the same terms used in the meetings between the domain experts and IT people will show up in domain models, tables, and programs. That’s why the name of this pattern is ubiquitous language, which is a single language used everywhere to keep things clear and consistent.

However, when people talk, some words can have different meanings depending on the situation. For instance, in a sales context, “customer” might refer to someone who purchases goods, while in a support context, it could refer to someone seeking assistance. This dubiousness isn’t a problem for human conversations, but software programs don’t admit ambiguities, everything must have one clear definition.

To overcome this problem, strategic DDD has the bounded context pattern. The idea is just like the name suggest, we delimit a context to the meaning of our terms. In our previous example of the term “customer”, we would have a bounded context named “sales” and another one called “support”. Therefore, inside de “sales” bounded context, the word “customer” is going to have exactly one meaning.

Microservices and Domain-Driven Design

In a microservices architecture, getting the size of our services right is very important. If they are too big, they become individually very complex and difficult to maintain. On the other hand, if they are too small, the global complexity of lots of tiny microservices communicating between them is going to be high. DDD helps us with some heuristics: a service shouldn’t be bigger than the bounded context, or else our language won’t be clear, and the software could get really complicated. Usually, the size of a microservice fits well with a subdomain. The application boundaries will follow how the business works, and new features from businesspeople typically get added to a single microservice, without causing a ripple effect where multiple microservices will need to be changed and deployed together.

Strategies and Tactics

Strategies serve as guiding principles that steer us towards optimal choices, offering a roadmap to attain overarching objectives. Whether aiming to triumph in a chess match or excel in a software project, strategies outline the trajectory for long-term success. In contrast, tactics are more about quick results. They focus on getting things done in a short amount of time.

Chess Tactics

Chess tactics are clever tricks that players use to catch their opponents off guard or win quickly. One famous tactic is the double attack. This happens when a single move creates two problems for the opponent, and they can’t solve both. Look at the picture below: the Knight is attacking both the King and the Rook at the same time. The opponent must move the King, and in the next turn, he will lose the Rook.

Domain-Driven Design Tactics

While strategic DDD provides us with guidance for comprehending business requirements and crafting software solutions aligned with company objectives, tactical domain-driven design operates within the practical realm of coding programs. The three most recognized tactical patterns of DDD are value objects, entities, and aggregates.

Value objects are important components in programming that help us represent specific pieces of information, like dates or money amounts, in a clear and consistent way. They’re like little containers for data and rules that make our code easier to understand and maintain. Value objects are special because once we create them, we can’t change them, which keeps our data reliable. They’re like building blocks that help us create strong and reliable software. Value objects can be identified by the composition of their values.

Entities are essential in programming as they represent the core elements in a system that have unique identities and behaviors. Just like characters in a story, entities hold important information and can interact with each other. These objects help us model real-world concepts, like customers or orders, making our software more reflective of the actual situation. Because entities have individual identities, they’re crucial for tracking and managing data accurately. In programming, entities act as the main characters that drive our applications.

Aggregates are vital in programming because they group together related entities and value objects, creating a more organized structure for our code. Think of them as containers that hold everything needed to handle a specific part of our system. Aggregates help us manage complex data and interactions by providing a clear boundary for operations. This makes our code more understandable and reduces the chances of errors. In programming, aggregates act as the guardians of consistency and integrity, ensuring that our data stays accurate and dependable.

Final Words

To wrap things up, both DDD strategy and chess strategy guide our choices. Imagine strategy as a big plan for the long run, and tactics as practical steps for right now. It’s like having a map for the journey and tools for the adventure. Despite the differences between chess and IT, they both share a common goal: a desire for success. In chess, we aim to win the match, and in IT, we strive to succeed in our projects.

The post Strategic Moves: Exploring the Chessboard of Domain-Driven Design appeared first on Blog do Banco do Brasil.

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.

The post Movimentos estratégicos: explorando o tabuleiro de xadrez do Domain-Driven Design appeared first on Blog do Banco do Brasil.