Vaughn Vernon é um desenvolvedor de software e arquiteto com mais de 35 anos de experiência atendendo diversos domínios de negócio. Além disso, é um reconhecido especialista em Domain-Driven Design. Seus livros são usados como referência para programadores em todo o mundo.

Neste post, compartilhamos uma pequena entrevista com Vernon, onde ele gentilmente compartilhou algumas opiniões sobre DDD e desenvolvimento de software em geral.

Nós, da EximiaCo, somos gratos a Vernon por gentilmente encontrar tempo em sua agenda para responder essas questões.

Questão #1 – Qual é a relevância e como está a adoção de DDD nos dias de hoje?

Vernon – Na minha opinião, DDD é mais relevante que nunca e a adoção continua crescendo. DDD já tem mais de 15 anos, o que significa que já não é, em nenhuma perspectiva, um hype. A razão porque continua relevante é que arquitetos e desenvolvedores estão tremendamente cansados de falharem por arquiteturas e implementações baseadas em decisões arbitrárias. É sabido, por meio de inúmeras experiências, que boa arquitetura e design de software não são obtidas sem esforço.

Questão #2 – Você recomenda algum “roteiro de estudos” para aqueles que desejam aprender DDD hoje?

Vernon – A coisa mais importante para aprender DDD é praticar em projeto. Mesmo assim, muitas pessoas enfrentam dificuldades para aprender em função da mudança de mindset que DDD exige.

Escrevi dois livros sobre o assunto, “Implementing Domain-Driven Design” e “Domain-Driven Design Distilled“. Também produzi um vídeo baseado em “Domain-Driven Design Distilled” e continuo ensinando DDD em um workshop ministrado globalmente (mais detalhes em IDDDWorkshop.com). Ou seja, eu mesmo produzi material tanto para aqueles que querem aprender DDD por conta, quanto para aqueles que demandam acompanhamento em workshops intensivos com 3 dias de duração

Minha recomendação é começar assistindo “Domain-Driven Design Distilled” em vídeo e lendo o livro “Domain-Driven Design Distilled”  – ambos estão disponíveis on-line. “Implementing Domain-Driven Design” é um conteúdo muito mais denso, podendo ser utilizado como material de referência até mesmo em projetos. Eventualmente, eu também ofereço serviços de consultoria, mesmo remotamente,  para ajudar times.

Questão #3 – Qual seria sua recomendação para quem quer se aperfeiçoar em DDD, mesmo já tendo larga experiência? O que eles estão provavelmente ignorando?

Vernon – É necessário ter boas conversas com os especialistas de domínio. Não há outra coisa mais importante, porque as “conversas” resultam no desenvolvimento da linguagem onipresente e em contextos delimitados. Este é aspecto central do DDD e ainda não há indicativos de que os esforços para aproximar os times de negócio e de desenvolvimento estejam suficientes. Os padrões táticos de DDD não funcionam se os padrões estratégicos não forem empregados, e as bases estão na identificação do contexto delimitado e na explicitação da linguagem onipresente. Eu, inclusive, já desenvolvi ferramentas para ajudar no mapeamento da topografia do contexto.

Questão #4 – Com a popularização dos microsserviços, DDD é mencionado frequentemente como referência para “quebrar” o monolito em partes. Quais são suas percepções sobre isso?

Vernon – Os contextos delimitados talvez sejam a primeira boa abordagem para identificar, arquitetar e projetar microsserviços. A maioria dos desenvolvedores parece se interessar pela parte “micro” de microsserviços, tentando criar explicações precisas para determinar o tamanho ideal de cada serviço. Se você usa DDD, acaba encontrando uma alternativa ideal pois a linguagem onipresente acaba apontando um tamanho ideal para cada serviço, nem pequeno, nem grande demais. Depois disso, basta achar boas justificativas para fazer o deploy em partes menores, sem prejuízos ao contexto.

Questão #5 – DDD é frequentemente associado com programação orientada a objetos. Nós sabemos que você tem defendido e aplicado DDD com modelo de atores e programação funcional. Gostaria de compartilhar suas impressões?

Vernon – Depois de décadas usando de maneira ineficiente o hardware, que tem enorme poder computacional, muitos arquitetos e desenvolvedores entenderam que precisam revisar a forma como implementam software. Esta é uma das razões tanto para microsserviços quanto para abordagens reativas. A programação funcional também está crescendo em popularidade. O modelo de atores não é um conceito novo e tem sido adotado em cenários mais avançados, robustos e, eventualmente, rock-solid por décadas.

Por causa disso, eu iniciei uma iniciativa open-source para desenvolver o vlingo/PLATFORM. Trata-se de um conjunto de ferramentas tanto para projetos de microsserviços que empregam DDD quanto os que não utilizam. Ele suporta abordagens Event-Driven, Message-Driven, Reactive para desenvolvimento de software e tem implementações tanto em Java como em .NET. Em fevereiro de  2020, lançaremos a versão 1.2.0 para Java enquanto a versão para .NET se aproxima da versão 1.0.0. Há suporte para abordagens usando HTTP e mensageria, event sourcing CQRS e process managers (Sagas).

Questão #6 – Quais são suas recomendações mais importantes para desenvolvedores em 2020?

Vernon – Meu mantra atual é que todos os desenvolvedores e arquitetos dediquem tempo para aprender três coisas:

1. Conway’s Law,
2. Conway’s Law,
3. Modularização.

Os dois primeiros itens da lista não são os mesmos por engano. A intenção é dar ênfase para como as leis de Conway impactam as soluções que desenvolvemos. A necessidade de lembrar, constantemente, a lei de Conway não pode ser subestimada. Ela determina todos os resultados que obteremos. O terceiro item trata de aprender a modularizar aplicações adequadamente. DDD ajuda bastante tanto com Conway’s law quanto com modularização.