Exibir código-fonte para DDD

= Objetivo =
<p style="text-indent: 2em;">Desenvolver um conteúdo que demonstre os conceitos fundamentais sobre o '''DDD''', a importância desse conhecimento para o desenvolvimento profissional e pessoal do programador e como esse tópico se relaciona com outros temas importantes na área da computação </p>
<br>

= Introdução =
<p style="text-indent: 2em;">
No processo de desenvolvimento de sistemas, o '''design de software''' assume um papel importantíssimo ao tentar converter um '''problema do mundo real''', tangível ou não, em software por meio de ferramentas, processos, metodologias e dentre outros métodos. Dentre essas diversas metodologias, assim como escrito na obra de referência [2], encontra-se o '''DDD''', o qual significa ''Domain-Driven Design'', ou seja, '''Design Dirigido à Domínio'''. Essa ramificação do design de software, o qual auxilia na estruturação e no desenvolvimento de aplicações, tem mais relação em mostrar ao programador sobre como lidar com a necessidade do cliente e traduzir para uma '''linguagem de domínio''' (o conceito central quando se fala de DDD) do que com o código propriamente dito, não havendo muito código e nem descrição de ferramentas, linguagens, frameworks ..., sendo uma maneira de estabelecer uma '''comunicação clara e padronizada''' entre todas as partes (grupos de pessoas) envolvidas na criação do sistema. 
</p>
<br>

= DDD (''Domain-Driven Design'') = 
<p style="text-indent: 2em;">A obra de referência [2] traz uma reflexão interessante acerca do desenvolvimento de software. Ao considerar a fabricação de carros como metáfora, o autor ressalta que a especialização na confecção de partes do carro pode limitar a visão do todo:</p>

:: ''"The workers involved in auto manufacturing [...] often have a limited view of the entire car manufacturing process. [...] A good car starts with a vision. [...] Software development is similar. [...] You cannot create a banking software system unless you have a good understanding of what banking is all about."''

<p style="text-indent: 2em;">O autor estabelece que, assim como na engenharia automotiva, o software complexo exige design e visão prévia. Conclui-se, então, que o '''domínio do problema''' é pré-requisito para a codificação. Sem esse conhecimento de domínio, o software torna-se apenas um amontoado de funcionalidades desconexas, falhando em entregar o valor real esperado pela visão original do projeto. Mas afinal, o que é o domínio?</p>

<p style="text-indent: 2em;">O '''domínio''' pode ser entendido como o conceito central no ''Domain-Driven Design''. A obra de referência [1] define o domínio como a '''área de conhecimento à qual o usuário aplica o software'''. Consequentemente, o design da aplicação deve se construir em torno desse conceito e das necessidades de quem o utiliza. Nesse contexto, é crucial que a equipe técnica possua um entendimento profundo do domínio para o qual a aplicação é desenvolvida para que se possa criar um modelo computacional aderente à realidade. Para facilitar essa compreensão, existem alguns conceitos muito importantes que auxiliam na estruturação do problema de forma padronizada para os envolvidos.</p> 

<p style="text-indent: 2em;">O primeiro conceito a ser citado é o de ''Domain Experts'' ('''Experts de Domínio'''), que são as pessoas que vivenciam, dia a dia, as situações as quais o software tentará auxiliar e que entendem a problemática que a aplicação tenta resolver. Antes de começar a escrever código, o programador deve entender a fundo o problema do cliente para poder tratá-lo de forma fidedigna à realidade e clara para os que estão presentes no processo do desenvolvimento do software. Uma forma de compreender mais à fundo problema, é conversando com os ''Domain Experts''. Dessa forma, torna-se clara a importância da '''comunicação''' para o DDD.</p> 

<p style="text-indent: 2em;">Além disso, outro conceito de suma importância para o Design Dirigido à Domínio é a '''Linguagem Ubíqua''' (''Ubiquitous Language''). Após múltiplas conversas estabelecidas com vários ''Domain Experts'', é possível criar um vocabulário universal. Esse conceito visa resolver a falha de comunicação gerada quando os ''Domain Experts'' e desenvolvedores utilizam vocabulários distintos: enquanto os primeiros têm um entendimento limitado acerca dos jargões técnicos, os segundos tendem a abstrair o sistema em termos puramente funcionais. Conforme exposto na obra de referência [1], depender de traduções constantes entre esses dois grupos resulta em perda de informações e em um software que não reflete a realidade do negócio; portanto, é importante estabelecer uma '''linguagem comum''' baseada no modelo de domínio, utilizada tanto nas discussões verbais e diagramas quanto na própria escrita do código-fonte.</p> 

<p style="text-indent: 2em;">Para lidar com a complexidade de grandes sistemas, a abordagem de ''Domain-Driven Design'' propoe decompor o problema em áreas menores, em '''Subdomínios''', estabelecendo fronteiras lógicas explícitas conhecidas como ''Bounded Contexts'' ('''Contextos Delimitados'''). Dentro de cada uma dessas fronteiras, a linguagem é unificada e livre de ambiguidades, protegendo a integridade do modelo e permitindo que conceitos semelhantes possam ter comportamentos distintos dependendo do contexto em que estão inseridos (a palavra 'Cliente' pode significar algo totalmente diferente para o setor de Vendas e para o setor de Logística).</p>

<p style="text-indent: 2em;">Dentro dessas fronteiras, a riqueza do modelo é expressa através da distinção entre '''Entidades''' — objetos que têm uma identidade única e continuidade ao longo do tempo — e ''Value Objects'' ('''Objetos de Valor'''), que são imutáveis e definidos apenas pelos seus atributos descritivos. Para assegurar a consistência dos dados e impor regras de negócio invariantes, esses objetos são organizados em ''clusters'' chamados '''Agregados'''. O Agregado funciona como uma 'cápsula' de segurança: nada de fora pode mexer nas peças internas diretamente, garantindo que as regras de negócio nunca sejam quebradas.</p> 

<p style="text-indent: 2em;">Por fim, a operacionalização desse modelo ocorre na camada de aplicação através dos '''Casos de Uso''', que são basicamente os roteiros das tarefas que o usuário deseja realizar (como 'Finalizar Compra'). Quando uma regra de negócio é satisfeita e gera uma mudança de estado relevante, o sistema dispara '''Eventos de Domínio'''. Esses eventos atuam como 'mensageiros' do que ocorreu no passado, permitindo que outras partes do sistema fiquem sabendo o que aconteceu e reajam a esse fato do passado, sem que uma parte do código precise ficar rigidamente presa à outra.</p> 
 
<br>

= Conclusão = 
<p style="text-indent: 2em;">Portanto, o ''Domain-Driven Design'' é essencial para a construção de softwares complexos que sejam '''robustos, estáveis e fiéis à realidade do negócio'''. Mais do que uma abordagem técnica, a adoção do método impulsiona a evolução do desenvolvedor, exigindo o aprimoramento de ''hard'' e ''soft skills''. Logo, o DDD, além de elevar a qualidade da aplicação final, auxilia na reputação profissional de quem o pratica.</p> 

<br>

= FAQ =  
* O que é DDD? 
* Posso aplicar apenas os elementos táticos do DDD sem passar pelo design estratégico? 
* Ser orientado à eventos é necessário para implementar DDD? 

<br>

= Referências =  
[1] 
 @book{evans2003domain, 
   title={Domain-Driven Design: Tackling Complexity in the Heart of Software}, 
   author={Evans, Eric}, 
   year={2003}, 
   publisher={Addison-Wesley Professional}, 
   address={Boston, MA}, 
   isbn={978-0321125217} 
 }
<br>
 

[2] 
 @book{avram2006domain, 
   title={Domain-Driven Design Quickly}, 
   author={Avram, Abel and Marinescu, Floyd}, 
   year={2006}, 
   publisher={C4Media}, 
   address={San Francisco, CA}, 
   isbn={978-1411609259} 
 }
<br>
 

[3] 
 @misc{dddpractitioners_faq, 
   author       = {{DDD Practitioners}}, 
   title        = {{FAQs - DDD Practitioners}}, 
   howpublished = {\url{https://ddd-practitioners.com/home/faqs/}}, 
   note         = {Acessado em: 25 nov. 2025}, 
   year         = {n.d.} 
 }

= Autor =
* Enzo Santos Tavares
** {enzo.tavares@ufu.br}