Humanizando seu Domínio

Olá tudo bem? No dia 26/09, André Baltieri, José Roberto Araújo, Robson Castilho, Yan Justino e Eu, realizamos nosso primeiro cast que tem como foco o Domain-Driven-Design. Neste primeiro cast, o tema foi “Humanizando seu domínio” e aqui, neste post, vou fazer o resumo do assuntos abordados.

Origem do DDD

O primeiro livro a ser publicado foi em 2004, pelo seu criador, Eric Evans, com o titulo: Domain-Driven-Design Tackling Complexity in the Heart of Software. Apesar da publicação ser relativamente recente, muitos dos conceitos e características discutidas no livro não são novas.

Atualmente, o livro escrito por Evans não é a única literatura disponível sobre DDD. Após sua publicação, Tivemos  algumas outras ótimas publicações. Aqui você encontra todo material literário já produzido.

O que é?

Eu gosto bastante da definição que o Scott Millett faz em seu livro, onde ele diz que: “Domain-Driven-Design é uma filosofia (ou abordagem) de desenvolvimento de software, utilizada para construir softwares com domínios complexos”. Para tal, esta filosofia de desenvolvimento nos fornece um conjunto de padrões, princípios e práticas que, possibilita ao time de desenvolvimento, focar no que é o coração do negócio.

Domínio

Sempre que trabalhamos no desenvolvimento de um software, você pode até não saber/conhecer, mas estamos trabalhando no domínio.

Em um sentido amplo, podemos dizer que o domínio é o que uma organização faz e o “mundo” que ela habita. O seu “mundo” de compreensão e a forma como realiza suas operações é o seu domínio. Uma empresa educacional ou um empresa de logística, cada uma possui seu domínio. É este tipo de domínio que estamos nos referindo na citação acima (não no modelo de domínio, assunto que falaremos mais adiante).

Tendo isso em mente, quando possuímos um  domínio complexo, isto é, um domínio de negocio não trivial, possuímos um ambiente favorável e adequado para a aplicação desta filosofia de desenvolvimento.

Como DDD pode nos ajudar?

Antes de tudo, Domain-Driven-Design não é sobre tecnologia, os seus principais princípios estão focados em: entendimento, descobrimento, discussão e não menos importante, valor de negócio.

Sabendo disso, podemos ler nas entrelinhas que, antes de codificar, devemos entender o domínio do negócio que o software a ser desenvolvido irá atacar.

Para atingir está compreensão sobre o domínio, o DDD nos fornece um conjunto de padrões estratégicos. Este padrões auxiliam na aproximação de desenvolvedores e experts de domínio, valorizando, como já dito, a comunicação e discussão.

Com este tipo de relação, os feedbacks sobre a discussão, entendimento e destilação de um modelo mental ocorrem com maior frequência, disparando insights e alertas de possíveis erros de uma forma mais rápida, afim de encontrar as reais necessidades e possibilitando a criação de um software que expresse o modelo mental do expert de domínio. Isto ocorre porque ambos estão em constante discussão e descobrimento sobre o domínio.

Após a conclusão desta primeira etapa, para que o software seja construido respeitando este modelo e para dar forma a uma arquitetura, o DDD nos fornece um conjunto de padrões táticos.

Não se preocupe, falaremos mais adiante, em detalhes, sobre os padrões táticos e estratégicos que o DDD nos oferece.

Expert de domínio

O Expert de domínio não é um cargo. São pessoas que conhecem muito bem o negócio em que você está trabalhando. Estas pessoas são, provavelmente, aquelas que possuem um alto conhecimento sobre o domínio do negócio, como vendedores em uma empresa de varejo, por exemplo.

DDD em tudo?

Como vimos até agora, o Domain-Driven-Design é uma excelente abordagem para identificarmos onde estão as reais necessidades e, consequentemente, onde se encontra o real valor do negocio (ROI). Sendo assim, não desperdice tempo e esforço em aplicar estas abordagens em subdomínios que não irão trazer um alto valor para o negócio. DDD é para simplificar!

Quando usar?

Algumas sugestões onde o DDD pode vir a ajudar :

  • O DDD é bem vindo em casos onde não se conhece o domínio, por ser algo novo para o time.
  • Onde existe uma frequente mudança no negocio
  • Em casos onde não é possível identificar uma alta complexidade de inicio, mas o time possui duvidas se este cenário possa vir a crescer em complexidade

 

O que DDD não é

Acredito que, até agora, deixamos bem claro o que o DDD é e qual seu objetivo. Agora, para minimizarmos ao máximo qualquer tipo de confusão, vamos deixar claro o que o DDD não é.

Não é um modelo arquitetural para desenvolvimento de software. Ele simplesmente garante que o modelo de domínio seja isolado de qualquer complexidade técnica, garantindo que o foco esteja no domínio.

Não é um padrão, é uma filosofia de colaboração com foco na entrega de um software que gere alto valor, com base na comunicação.

Conclusão

Bem pessoal, fiz um resumo do que discutimos no nosso cast e a principal mensagem que gostaríamos de passar. Domain-Driven-Design vai além do código e tem como base fundamental a comunicação e precisamos ter em mente isso.

Não se preocupe se existem termos que foram citados aqui que você ainda não conhece, este foi só o primeiro de uma serie de casts que faremos focado em Domain-Driven-Design. Todos estes termos serão abordados logo mais.

Caso você ainda não tenha assistido nosso cast, deixo o link abaixo.

Não deixe de comentar! Sua opinião é fundamental para melhorarmos e esclarecermos qualquer duvida que venha a surgir 🙂

 

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s