Primeiras aulas do curso
Olá! Seja bem-vindo ao curso de modelagem estratégica com o Domain Driven Design. Meu nome é Vinícius Albano, sou instrutor na Alura.
Audiodescrição: Vinícius é um homem branco, com cabelo castanho e barba curta. Ele está em seu escritório, gravando com uma luz azul ao fundo e algumas decorações.
Neste curso, vamos explorar a modelagem estratégica com o Domain Driven Design, voltada para pessoas desenvolvedoras, líderes técnicos e também para quem trabalha com produto e está diretamente envolvido na etapa de desenvolvimento. O objetivo é aprender toda a etapa de modelagem estratégica utilizando o Domain Driven Design.
O que isso significa? Basicamente, vamos orientar nosso desenvolvimento com base no negócio, trazendo todos os conceitos, intenções do usuário e metas de negócio para dentro do processo de desenvolvimento. Se o objetivo é aprender mais sobre isso e realizar um processo de desenvolvimento mais assertivo, este curso é ideal.
Vamos ver o que aprenderemos aqui? Primeiramente, vamos alinhar o foco de desenvolvimento com o negócio, discutindo o que nosso usuário precisa, quais são nossos casos de uso e o que o negócio precisa entregar no futuro.
Falaremos sobre como realizar uma descoberta colaborativa de domínio utilizando ferramentas como o Event Storming (tempestade de eventos). Aprenderemos a decompor e classificar o domínio em subdomínios e suas classificações estratégicas, como núcleo, suporte e genérico.
Além disso, aprenderemos a conectar esses subdomínios para gerar soluções através dos diferentes sistemas que compõem nosso domínio. Organizaremos nossos contextos ilimitados e os times responsáveis por eles.
Vamos explorar as dinâmicas de influência que cada equipe exerce sobre a outra e como isso pode impactar o processo de desenvolvimento. Também veremos como definir papéis e responsabilidades dentro de cada contexto delimitado, ou seja, o que acontece dentro de cada contexto e o que precisa estar presente.
Por último, abordaremos como preparar a codificação de um agregado. Existem diversas técnicas interessantes para determinar o que realmente faz parte de um agregado, o que não faz, e como identificar possíveis conflitos de concorrência e crescimento do agregado ao longo do tempo durante a codificação.
Com isso, teremos um panorama geral, partindo de um conceito amplo de negócio e afunilando cada vez mais, até chegar a soluções concretas que possam ser aplicadas em um código totalmente orientado ao negócio, resolvendo as questões necessárias.
Para aproveitar bem este curso, é importante já ter uma visão geral dos fundamentos do Domain Driven Design, como o que ele é, a linguagem ubíqua e os principais conceitos. A partir daqui, aplicaremos isso com diversas ferramentas para a modelagem estratégica.
É importante destacar que, neste curso, não faremos codificação de projeto, mas sim colocaremos a mão na massa através de diversas ferramentas práticas, de forma colaborativa entre as equipes de desenvolvimento, equipes de negócio, especialistas de produto e líderes técnicos.
A partir disso, desenvolveremos habilidades valiosas para, posteriormente, aplicar no código de forma assertiva. Sejam bem-vindos! Estamos animados para compartilhar essa jornada de aprendizado e nos vemos no próximo vídeo. Um grande abraço!
Sejam bem-vindos ao curso de modelagem estratégica com o Domain Dreaming Design. Estamos muito felizes em tê-los aqui conosco. Temos certeza de que este curso será de grande ajuda em suas carreiras como pessoas desenvolvedoras, auxiliando na entrega de sistemas mais robustos, resilientes e, principalmente, que realmente resolvam os problemas dos usuários. Não adianta termos sistemas bem arquitetados, com código limpo e uma boa estrutura, se não resolvem o problema final que o usuário deseja.
O Domain Dreaming Design é uma filosofia de desenvolvimento que se propõe a resolver o problema final, englobando todos os pensamentos e principais terminologias de negócio no processo de desenvolvimento de software. Este curso foi construído sobre o curso anterior de Fundamentos do Domain Dreaming Design, onde apresentamos um panorama sobre o que é o DDD, sua importância, modelagem estratégica, introdução à modelagem tática, linguagem ubíqua, contexto ilimitado, subdomínios, entre outros. Se ainda não assistiram a esse curso, recomendamos que o façam, pois neste curso mais aprofundado de modelagem estratégica, assumiremos que já possuem alguns conceitos sobre DDD. Embora acreditamos que conseguirão acompanhar, é importante ter um panorama geral antes.
Nesta aula, discutiremos o que é a modelagem estratégica e como transformá-la em uma vantagem competitiva para o seu negócio. Vamos utilizar como exemplo o UseDev, um projeto fictício de e-commerce voltado para o público geek, que aprecia produtos de tecnologia, games e quadrinhos. Escolhemos este cenário por estar relacionado ao nosso meio e pelo domínio de e-commerce, que é familiar para a maioria das pessoas. Provavelmente, já compraram algo online, interagindo com catálogos de produtos, carrinhos de compras, entre outros. Assim, acreditamos que conseguiremos trazer exemplos que serão familiares em suas vidas.
Falando sobre nossa proposta de valor, o UseDev oferece produtos geek curados, selecionando as melhores estampas e desenhos que realmente agregam valor à nossa comunidade, composta por desenvolvedores, gamers, nerds e entusiastas de tecnologia. Nosso público-alvo tem entre 18 e 45 anos, geralmente de classe média alta, com poder aquisitivo para adquirir esses produtos. Nosso modelo de negócio é B2C, ou seja, o UseDev vende diretamente para o consumidor. A pessoa acessa nosso site, escolhe um produto, realiza a compra e o recebe posteriormente.
Nosso MVP foi bem-sucedido, mas percebemos que existem outras lojas e fabricantes de produtos de tecnologia interessados em ter um canal de vendas. Assim, nosso time de negócios deseja transformar o UseDev em um marketplace, conectando-se com outros lojistas para que possam vender seus produtos em nossa plataforma. Com essa mudança, identificamos sintomas de desalinhamento. Atualmente, temos um código engessado, desenvolvido para o MVP e validação do negócio, utilizando muitos softwares prontos, como o catálogo de produtos no Shopify e provedores de pagamento facilmente integráveis. Isso resultou em um sistema genérico, não personalizado para nosso negócio.
Agora que desejamos personalizar o negócio, enfrentamos dificuldades. Partes estratégicas do nosso negócio estão presas em módulos genéricos, e precisamos trabalhar nisso. Além disso, nossos times são organizados por camadas técnicas, como front-end, back-end, banco de dados e DevOps, resultando em dependências cruzadas. O time de back-end desenvolve uma API, o time de front-end cria a interface de usuário para suportar essa API, e o time de DevOps cuida da implantação e configuração dos bancos de dados. Essa interdependência gera muita troca de comunicação e um pipeline de entregas interconectado, sem autonomia real.
Por fim, atualmente temos um monolito distribuído, o que também precisa ser abordado.
O time tomou algumas decisões equivocadas ao criar microserviços focados em integrações específicas, como no catálogo de produtos e na parte de pagamentos, o que gerou dependências de contexto entre esses microserviços. Isso impede que possamos escalá-los, pois não são autônomos. Precisamos, portanto, desacoplar esses microserviços para que se tornem realmente autônomos, com suas próprias regras de negócio e independência em relação a outros times.
Precisamos tratar a arquitetura do software para aprimorar a construção dos sistemas. Atualmente, enfrentamos desafios de crescimento. Com o MVP validado, o time de negócios pressiona o time de tecnologia. Já realizamos várias integrações genéricas, mas agora precisamos ganhar ritmo, personalizar as soluções e eliminar a dívida técnica. O time de tecnologia está sob pressão por escala, velocidade e qualidade de entrega. As decisões técnicas que tomarmos serão estratégicas para o negócio, influenciando o ritmo de crescimento e a organização futura da empresa, além de priorizar as entregas.
Vamos discutir o roadmap do negócio. Somos um B2C, um external marketplace, e precisamos de funcionalidades como gestão de vendedores, cálculo e pagamento de comissões, e aprovação de produtos para oferta na loja. Também queremos personalizar produtos, atendendo à demanda por produtos exclusivos da UseDev, permitindo que clientes personalizem presentes com nomes ou imagens especiais. Isso requer recursos únicos, como uma pipeline de processamento de imagens e serviços de impressão sob demanda, além de integrações extras para suportar esse novo caso de uso.
Temos um sócio com um ERP legado, cuja API é inconsistente e sem documentação. Precisamos integrá-lo de forma eficaz, protegendo nossos sistemas da UseDev de detalhes internos do ERP e facilitando uma eventual migração para outro ERP. Para isso, é necessário usar uma camada de abstração.
Nosso time de produtos também está interessado em um projeto de gamificação e fidelidade, onde clientes ganham pontos e níveis ao fazer compras na UseDev, podendo trocá-los por descontos e benefícios exclusivos. Acreditamos que isso será uma adição valiosa.
Enfrentamos o desafio da migração arquitetural. Atualmente, temos um monolito distribuído com microserviços não autônomos. Queremos migrar para microserviços verdadeiros, com responsabilidade única sobre seus contextos. Considerando que você está liderando o projeto, como expandiria o negócio a partir do MVP genérico? Como tornaria as soluções robustas e decomporia os sistemas para maximizar a autonomia, não apenas em deploy e regras de negócio, mas também entre os times?
Como podemos evoluir de times de front-end, back-end e DevOps para times autônomos, sem sobreposição de responsabilidades? Como minimizamos a dívida técnica, entregando soluções robustas sem sobre-engenharia? Como alinhamos decisões arquiteturais com a evolução do negócio, priorizando o desenvolvimento e a entrega de novas funcionalidades?
Tudo isso é crucial para a evolução do negócio. Reflita sobre essas questões, e em breve discutiremos modelagem estratégica e como ela auxilia no planejamento. Até logo!
Agora que já refletimos um pouco sobre como realizar aquele projeto, considerando que estamos na liderança do time, vamos abordar a fórmula do DDD Estratégico e o que ele representa. Primeiramente, vamos discutir a Lei de Conway. Basicamente, a Lei de Conway afirma que qualquer organização que projeta um sistema produzirá um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização. Isso significa que, ao criar projetos e sistemas, não necessariamente de software, a forma como modelamos esse sistema é diretamente influenciada pela estrutura de comunicação da organização.
Não se trata apenas do organograma ou da hierarquia dos times, mas também de como eles se comunicam. Por exemplo, dois times que não estão próximos hierarquicamente podem estar próximos fisicamente no local de trabalho, o que facilita a comunicação entre eles. Essa proximidade pode influenciar o sistema, refletindo a comunicação entre esses times. Isso tem um impacto significativo no desenvolvimento de software, pois, se nossos sistemas refletem a estrutura da organização, como podemos criar um sistema verdadeiramente modular e autônomo em suas partes? Essa é uma questão complexa.
Vale a pena discutir que a arquitetura do software é uma construção sociotécnica. Isso significa que, além do código e da qualidade dele, o mais importante são os times que representam esse código, as pessoas que o constroem e a comunicação entre esses times. Se quisermos criar uma aplicação modular, com partes independentes, precisamos fazer o inverso da Lei de Conway. Ou seja, devemos organizar nossos times de forma que a arquitetura seja desacoplada. Se precisamos que dois módulos do sistema conversem entre si, é essencial que as equipes responsáveis por esses módulos também se comuniquem. Se queremos que dois módulos tenham autonomia, as equipes que os desenvolvem também precisam ter autonomia, evitando sobreposição de responsabilidades.
A Lei de Conway oferece uma visão interessante. Já refletimos sobre como resolver isso, mas, basicamente, a solução para tomar decisões de negócio e aplicá-las no desenvolvimento é a modelagem estratégica do domínio de Event Design (Design de Eventos). Isso envolve, entre outros aspectos, os core domains (domínios principais), que trazem vantagem competitiva para o negócio, e como diferenciá-los dos demais. Também abordamos os bounded contexts (contextos delimitados), que definem as fronteiras de autonomia entre nossos módulos do sistema e entre os times que os desenvolvem.
Discutimos ainda o baixo acoplamento entre os diferentes módulos do sistema. Com vários módulos diferentes, é importante garantir que a comunicação entre eles não vaze contexto de um para o outro, evitando que mudanças em um módulo impactem seriamente outro. O DDD estratégico oferece ferramentas para isso. Por último, mencionamos o Fast Flow, uma ferramenta complementar ao DDD estratégico, relacionada a Team Topologies (Topologias de Equipe), que ajuda a organizar equipes de forma orientada ao fluxo de negócio, promovendo independência.
A modelagem estratégica envolve o conceito de Bounded Context (Contexto Delimitado), que é um limite onde o modelo do software é aplicável, geralmente relacionado à linguagem. Quando termos de negócio são usados de forma diferente em diferentes times ou áreas do sistema, isso geralmente indica sistemas diferentes, possivelmente até microserviços distintos. O contexto delimitado é a fronteira de consistência e autonomia, preservando a linguagem ubíqua e as regras de domínio.
Devemos diferenciar subdomínios de contextos delimitados. O subdomínio é o espaço do problema, no campo do negócio, onde o time de produto se preocupa em resolver problemas e atender às necessidades do usuário. O subdomínio ajuda a separar diferentes problemas que a empresa ou o software precisa resolver. Já o contexto delimitado está na parte da solução, indicando como resolver o problema identificado.
Que tipo de solução vamos aplicar? Como vamos organizar nossos times e sistemas para que, em conjunto, resolvam os problemas? É essencial compreender a diferença entre subdomínio e contexto delimitado. Vamos agora discutir os diferentes níveis do Domain Driven Design (DDD). Basicamente, são dois: o nível tático e o nível estratégico.
No nível tático, damos um zoom no projeto de DDD, chegando ao nível do código, no baixo nível. Discutimos agregados, entidades, objetos de valor e repositórios, tudo isso na implementação. No entanto, este curso foca na parte estratégica, que se distancia do espaço de solução e aborda o espaço do problema, organizando-o para projetar soluções.
No nível estratégico, falamos sobre contextos delimitados, subdomínios, mapas de contextos e a organização dos times. Este curso enfatiza como desenhar o sistema antes de codificar, definir divisões entre contextos delimitados, identificar partes prioritárias e estabelecer a comunicação entre equipes.
Vamos fazer um panorama sobre a relação entre o DDD estratégico e o tático. No foco estratégico, discutimos contextos delimitados e subdomínios. No tático, abordamos a agregação de entidades e outros padrões de implementação do código. Em termos de escopo, a estratégia abrange o sistema sociotécnico completo, incluindo times, sistema, regras de negócio, variações, clientes e suas necessidades. No tático, o escopo é dentro de um contexto delimitado, selecionando uma parte dos problemas para expandir e implementar a solução.
Algumas perguntas relacionadas ao nível estratégico incluem quantos contextos existem, quais são core (aqueles que geram diferencial competitivo), quais são de suporte e quais são genéricos. No nível tático, as perguntas focam em como modelar invariantes, preservar comportamentos dentro do contexto delimitado e evitar impactos de outros contextos.
As ferramentas no nível estratégico incluem event storming e mapas de contexto, entre outras que serão apresentadas no curso. No nível tático, temos ferramentas voltadas à codificação, como diagramas UML e padrões de modelagem de eventos.
O momento para a parte estratégica é antes da codificação, quando ainda estamos pensando no espaço do problema, em contato com usuários, levantando requisitos e modelando a solução. A parte tática é usada durante a implementação, organizando padrões táticos para um código robusto com separação de responsabilidades.
Pode surgir a dúvida sobre por que não estamos vendo o código ainda. No primeiro curso, introduzimos padrões táticos, mas agora focamos na estratégia. Partir direto para a codificação pode gerar problemas, como agregados grandes sem fronteiras corretas, devido à falta de delimitação do espaço do problema e definição clara das responsabilidades.
Sem a parte estratégica, podemos ter acoplamento indesejado entre contextos, dificultando a manutenção e evolução do sistema. Além disso, podemos ter sobreengenharia em módulos genéricos, aplicando padrões táticos onde não são necessários e não aplicando onde são essenciais.
É crucial ter uma visão estratégica antes de iniciar a codificação. Em seguida, apresentaremos a modelagem estratégica do DDD na visão original de Eric Evans e uma ferramenta atualizada para auxiliar no processo de descoberta do domínio e modelagem da solução. Fiquem conosco para mais informações.
O curso DDD: modelagem estratégica de sistemas possui 467 minutos de vídeos, em um total de 84 atividades. Gostou? Conheça nossos outros cursos de JavaScript & Node.js em Back-end, ou leia nossos artigos de Back-end.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
Todos os cursos, trilhas e certificados para evoluir.
7 dias para cancelar com reembolso
Aprenda mais rápido com IA, idiomas e imersões.
7 dias para cancelar com reembolso
TUDO DO PLUS, MAIS:
Aceleração de carreira: mentoria, vagas e prática guiada.
7 dias para cancelar com reembolso
TUDO DO PRO, MAIS:
