Domain-Driven Design em Python: da modelagem de domínio à arquitetura de sistemas

Princípios do Domain Driven Design - Introdução

Apresentando o instrutor

Olá! Meu nome é Salmeidabatista e serei o instrutor deste curso.

Audiodescrição: Salmeidabatista é um homem branco, com cabelo curto castanho e olhos castanhos. Ele veste uma camisa social azul e está em um escritório com uma estante de livros ao fundo.

Possuo 20 anos de experiência em desenvolvimento de software, tendo trabalhado em diversas áreas, como e-learning, e-commerce, contabilidade, sistemas hospitalares e sistemas de meios de pagamento. Atualmente, sou Tech Lead em uma grande empresa de meios de pagamento. Sou formado em Ciência da Computação e pós-graduado em Banco de Dados. Já trabalhei com várias linguagens, como C#, Golang, Python e JavaScript. Atualmente, minha atuação principal é na área de back-end, com foco em sistemas distribuídos, onde os microserviços se encontram.

Introduzindo o Domain Driven Design

Neste curso, vamos aprender sobre Domain Driven Design (Design Orientado por Domínio), mas o que é Domain Driven Design? Ele possui duas partes: a parte estratégica e a parte tática. Independentemente disso, o que ele busca abordar é como lidar com as complexidades de um domínio complexo em um sistema. O objetivo é desenvolver um sistema que seja mais fácil de criar e manter.

É importante não pensar que Domain Driven Design é apenas código. Trata-se de uma mentalidade. Neste curso, vamos explorar profundamente tanto a parte teórica quanto a prática, por meio do desenvolvimento de sistemas utilizando o Domain Driven Design.

Estamos preparados para entrar no mundo do Domain Driven Design?

Princípios do Domain Driven Design - Desenvolvendo um software sem DDD

Introduzindo a aula sobre práticas comuns em projetos

Olá, sejam bem-vindos a esta aula. Nesta aula, vamos discutir como normalmente se inicia um projeto quando não se utiliza Domain-Driven Design (Design Orientado por Domínio). Vamos abordar algumas práticas comuns nesse contexto.

A primeira abordagem é a equipe focar inicialmente no banco de dados. Normalmente, a equipe deseja configurar o banco de dados, criar os schemas, as tabelas, e as operações de CRUD (Create, Read, Update, Delete), além de criar endpoints. Esse tipo de abordagem é conhecido por espelhar o código conforme o estado atual do banco de dados.

Exemplificando a criação de endpoints básicos

Para ilustrar essa abordagem, podemos considerar a criação de endpoints básicos, como o POST /user e o GET /orders. Esses endpoints são exemplos de como a equipe pode começar a implementar funcionalidades sem um entendimento profundo do domínio, focando apenas nas operações básicas de CRUD.

POST /user
GET /orders

Abordagens focadas em tecnologia e suas consequências

A segunda abordagem ocorre quando o time não busca entender o negócio, mas se preocupa prematuramente com a tecnologia. A equipe já está preocupada com a arquitetura que será utilizada e em criar o software antes mesmo de ter esse entendimento. Assim, acabam criando o POST /user, o GET /orders, entre outros.

A terceira abordagem é quando o código está espalhado por todo o sistema, entre controllers, services e também pelo framework. Existem regras de negócio dentro do framework, e isso resulta em problemas quando trocamos o framework utilizado pelo software, pois muitas regras de negócio estão ocultas. Filtros, exceções e outros elementos estão envolvidos. Esse tipo de abordagem é conhecido como complexidade acidental, pois a complexidade não vem do domínio ou das regras de negócio, mas sim de um mau design escolhido desde o início.

Problemas decorrentes das abordagens inadequadas

Quais são os problemas decorrentes dessas abordagens? O primeiro problema é a falta de entendimento do negócio. Como o time de desenvolvimento não se dedica a conhecer o negócio junto com os especialistas de domínio, o software acaba sendo apenas uma simplificação de como o negócio funciona. No mundo real, o negócio opera de uma forma, mas as regras são bastante simplificadas quando transferidas para o software, devido à falta de entendimento por parte da equipe.

O segundo tipo de problema que enfrentamos é o código difícil de evoluir. A cada novo requisito, encontramos dificuldades para incrementar as regras, pois elas estão espalhadas em vários ambientes. Isso torna o sistema difícil de manter, testar e evoluir.

Consequências da baixa expressividade e do over-engineering

O terceiro problema é a baixa expressividade. Quando os softwares são desenvolvidos corretamente e modelam o domínio conforme o negócio funciona na vida real, eles se tornam um ativo. Isso ocorre porque as pessoas podem tirar dúvidas sobre como o negócio está modelado no software. No entanto, quando o software não é bem modelado, ele apresenta baixa expressividade, o que significa que não reflete como o negócio funciona. Isso gera problemas, pois muitas vezes a empresa precisa mudar sua forma de funcionamento porque o software não está modelado corretamente.

O último problema é o over-engineering (excesso de engenharia). Sabemos que nós, pessoas desenvolvedoras, gostamos de programar e de tecnologia, mas quando focamos apenas na tecnologia e não no negócio, acabamos fazendo over-engineering. Já vimos muitos cenários em que equipes enfrentaram esse tipo de problema, não estudaram a causa raiz e transformaram seus sistemas em microserviços. Quando um sistema é transformado em microserviço, mas o modelo está fragilizado, isso apenas complica ainda mais os problemas existentes. Nesse cenário, fazer microserviços seria um over-engineering, pois, em vez de solucionar o design e o modelo, estamos apenas complicando ainda mais. Muitos autores chamam isso de monolito distribuído, que ocorre quando criamos um mau microserviço.

Princípios do Domain Driven Design - Entendendo o que é Domain Driven Design

Introduzindo o Domain-Driven Design

Olá, na aula de hoje vamos explicar o que é Domain-Driven Design (DDD). Domain-Driven Design é uma abordagem de desenvolvimento de sistemas que foca em entender profundamente o negócio e traduzir esse entendimento diretamente para o código. DDD, como também é chamado, enfatiza a colaboração entre pessoas desenvolvedoras e especialistas de domínio por meio de uma linguagem compartilhada, permitindo que todos falem a mesma língua para que possamos criar modelos de domínio que reflitam o negócio.

Em vez de criar um banco de dados ou já começar a trabalhar na parte de tecnologia, DDD enfatiza a importância de aprender sobre o negócio. DDD tem uma abordagem orientada ao negócio. Agora, vamos explicar os benefícios que isso traz. Como isso altera o software? O primeiro ponto é: fale com o especialista de domínio. Em vez de começar a codificar imediatamente, o primeiro passo é aprender profundamente sobre o negócio. Para isso, precisamos encontrar os especialistas de domínio para que, nas conversas regulares, o negócio possa surgir como um modelo.

Explorando a Ubiquitous Language

Como isso acontece? Através dessas conversas, aprendemos regras de negócio, restrições e outros aspectos importantes. É fundamental que, por meio dos especialistas de domínio, aprendamos sobre o negócio, pois são eles que têm o domínio de como o negócio funciona. O segundo ponto é a utilização de modelos e conceitos centrais usando a Ubiquitous Language (linguagem ubíqua).

A Ubiquitous Language é uma linguagem compartilhada que deve ser visível não apenas para as pessoas desenvolvedoras, mas para todos que estão no sistema, incluindo as partes interessadas (stakeholders). Essa linguagem compartilhada deve estar presente nas reuniões, na documentação e, principalmente, no código. Muitos desenvolvedores cometem erros ao aprender o Domain-Driven Design (DDD) porque focam apenas no código. Devemos focar no comportamento do negócio. Em vez de nos preocuparmos com o armazenamento do sistema e o tratamento dos dados, devemos nos concentrar no comportamento do negócio. Por isso, é fundamental aprender profundamente sobre o negócio, pois assim aprendemos os comportamentos. É muito mais importante entender o comportamento do que como vamos armazenar os dados.

Delimitando Bounded Contexts e encapsulando regras de negócio

No que diz respeito ao design de Bounded Contexts, é importante criar fronteiras bem delimitadas, onde cada fronteira tem seu próprio domínio e sua própria linguagem. Em vez de criar um sistema inteiro ou um modelo completo de como o negócio funciona, devemos modelar pequenos modelos para facilitar a manutenção e evolução de cada um deles.

Por fim, devemos encapsular regras de negócio em domínios ricos. Devemos usar padrões como entidades, objetos de valor e agregados para capturar as regras de negócio, exceções e outros aspectos, em vez de espalhá-los por serviços e controladores. Assim, em vez de perguntar como iremos salvar algo, ao aprender o domínio de Domain-Driven Design, o correto, com o DDD, é perguntar quais são os comportamentos e regras desse domínio. Dessa forma, vamos aprendendo cada vez mais sobre o funcionamento do negócio.

Sobre o curso Domain-Driven Design em Python: da modelagem de domínio à arquitetura de sistemas

O curso Domain-Driven Design em Python: da modelagem de domínio à arquitetura de sistemas possui 553 minutos de vídeos, em um total de 144 atividades. Gostou? Conheça nossos outros cursos de Python em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• capitulo