Um bate-papo sobre DDD

Cara, estou trabalhando num projeto DDD!!

“Projeto DDD”? Bacana. Que negócio é esse?

Então…. tem uma separação em 4 camadas (Presentation, Application, Domain e Infrastructure) e um negócio de manter o ‘Domain’ separado de detalhes técnicos, como persistência.

Hmmm..arquitetura em camadas…e o que mais?

Uma série de patterns legais, como Value Object, Repository e Dependency Injection. Está sendo um desafio e tanto configurar tudo certinho no container de DI. Dá um certo trabalho entender com isso funciona.

Legal. E o que mais tem nesse DDD? Aliás, o que significa essa sigla?

A sigla significa Domain-Driven Design. Mais uma porção de coisas, como utilizar interfaces para desacoplar as camadas e também o uso do Entity Framework como ORM para cuidar da persistência dos objetos.

É outro grande desafio entender e configurar corretamente o Entity para lidar com o mapeamento dos objetos, lazy/eager loading, migrations,…. estou aprendendo bastante!

Imagino mesmo. Parece bem interessante. Me fala mais sobre o ‘Domain’. Ainda não tô entendendo onde isso tudo se relaciona com o nome ‘DOMAIN DRIVEN DESIGN’….

(Pensativo) Hmmm…bem…o ‘Domain’ é a camada onde ficam as regras de negócio. Nela, estamos usando o chamado ‘Modelo Rico’, ou seja, trabalhamos com um modelo orientado a objetos e, como eu disse antes, nosso ‘Domain’ é totalmente ignorante de detalhes de infraestrutura, ele só conhece as regras de negócio.

Isolar o que o seu software É (a área de conhecimento que ele atende) de detalhes técnicos, frameworks, databases, é uma ótima prática, sem dúvidas. Digamos que isso seja “implementar sua arquitetura de forma correta”, como, há décadas, explanado por diversos autores (vide ‘Ports and Adapters’, ‘Onion Architecture’, ‘Clean Architecture’ e similares).

E quem teve a ideia de utilizar DDD neste projeto?

Nós mesmos (os devs)!

E por que escolheram DDD?

(Pensativo) Bom, vimos na comunidade que muita gente está falando sobre o assunto, como uma boa prática. Estamos pensando em iniciar outro projeto com DDD também.

(Ficando preocupado) E do que se trata esse novo projeto?

É um projeto ASP.NET Web API. Já estamos estudando como usar DDD com ele.

(Notando que o buraco está ficando maior) Cara, estamos falando de muitas tecnologias e termos técnicos, mas, até o momento, não citamos muitos conceitos cruciais do DDD, sabia? Você já leu o livro do Evans? Alguém do projeto tem alguma experiência com DDD?

(Confuso) Não. Estou querendo comprar. Estamos seguindo alguns artigos e códigos de exemplo. E estamos todos aprendendo sobre o assunto neste projeto. Que pontos cruciais são esses? Então, você já sabia o que era DDD, né espertinho?

Sim. Estava te testando!! Faz 7 anos que estudo e pratico DDD. Aprendi bastante coisa e fiz inúmeras bobagens também, então, acho que sei um pouquinho sobre esse negócio.

Sinta-se tomando a pílula vermelha, ok?

OK!

Vamos lá! Tecnologias são importantes (e podemos bater um papo sobre elas em outro momento), mas tenho notado que DDD tem sido mencionado na comunidade como uma espécie de tecnologia – Web API + DDD, ASP.NET + DDD, TDD + DDD e similares – e as conversas sempre acabam indo para o lado de ferramentas (ORM), padrões (DI, Repository) e arquitetura (camada disso ou daquilo).

Isso me deixa bem preocupado. Preocupo-me pela possibilidade de estarem “usando DDD” por “estar na moda”, esquecendo-se daqueles tais pontos cruciais que mencionei…

Que seriam…?

DDD é um conjunto de práticas com o objetivo de construir um software de qualidade, que atenda as necessidades do cliente. Junto dessas práticas, temos a importância de trabalharmos próximos aos domain experts (pessoas da área de negócio que possam compartilhar conhecimento com os devs), entendendo a área de negócio do cliente e quebrando o problema em problemas menores.

Nesse processo, identificamos o core business do cliente e sub-áreas de negócio de menor importância, e podemos dar maior foco ao core business.

Foco no que importa mais para cliente -> Entregamos mais valor -> Melhor retorno sobre o investimento para o cliente!

Temos, aqui, conceitos como “Ubiquitous Language”, “Subdomains” e “Bounded Contexts” e diversas práticas em nível estratégico para trabalharmos com vários times, cada um atendendo uma parte do negócio.

No DDD, o foco está no domínio, que é a área de conhecimento para a qual você está criando uma solução, e na abstração deste domínio em 1 ou mais modelos, que resolvem problemas daquele domínio.

Tudo que mencionei agora são elementos fundamentais no DDD.

(Fazendo uma cara de “que conversa é essa?”)

Claro, ainda é software, e acaba sendo inevitável entrarmos em detalhes técnicos.

O Evans fala sobre arquitetura em camadas (as 4 das quais você falou no início da conversa) e também sobre patterns para ajudar no design do domain model (Entities, VOs, Services, etc..), os chamados “Building Blocks” do DDD.

Em livros mais recentes de DDD, fala-se mais ainda sobre implementação e arquitetura, entrando em práticas de integração (REST, messaging), CQRS/Event Sourcing, etc. Com isso, os autores pretendem entrar em algo mais prático, de modo que os leitores tenham uma ideia de como implementar o software seguindo os princípios do DDD. Assim, o assunto não fica extremamente abstrato e cansativo, como em muitas partes do livro do Evans.

No entanto, mesmo estes livros que focam bastante em código e integração, não se esqueceram dos pontos cruciais do DDD.

Hmm…

Veja, no início, também cometi muitos erros. Um dos principais erros era focar bastante no “micro”, o design do modelo e os padrões (Entities, VOs e afins), e esquecer do “macro”, identificar os subdomains e delimitar os contextos.

O domínio de uma técnica só vem através de EXPERIÊNCIA, o que não se ganha da noite para o dia. Com isso, chegamos à minha segunda preocupação com essa “moda do DDD”, se você ainda estiver com tempo de me ouvir…

Pode falar!

Um time inexperiente pode não dar muita atenção ao que eu disse sobre os pontos cruciais. É normal que a “gurizada”, como você (não se sinta ofendido), foque em aprender a usar as libs e frameworks do momento, sem se perguntar muito se aquilo resolve o problema.

DDD possui um conjunto grande de práticas, que servem para resolver um problema complexo. Entender e aplicar DDD corretamente não é o mesmo que aprender a usar aquela lib de data binding.

Minha preocupação é estarem iniciando projetos tentando aplicar DDD e estarem criando aberrações. DDD foi feito para simplificar e não complicar o que é simples!

Sendo assim, é fundamental que o time seja experiente e esteja extremamente empenhado em aprender DDD e entender o negócio. Por “time experiente”, entenda que seja um time onde haja, no mínimo, um líder que possa guiar o restante. Quanto maior e mais complexo o problema, mais necessária a presença de outros devs seniors.

E claro, a presença de Product Owners/Analistas de Negócio experientes também é fundamental.

Captou?

Acho que sim, e você me deixou com medo! Temos muitos problemas técnicos e nem todos são tão empenhados assim em estudar….

Desculpa, cara. Minha intenção não era te assustar ou ainda insinuar que vocês não são capazes. A intenção é ALERTÁ-LO a respeito das coisas que eu mencionei anteriormente.

Fazer software não é algo trivial e bobo. É preciso agir e tomar decisões com responsabilidade (afinal, alguém está pagando por ele e esperando por um ótimo produto).

Dá uma refletida no assunto e, se quiser, estou à disposição pra conversarmos mais em outros momentos.

OK. Irei pensar sim! Vou processar tudo que você falou e, com certeza, iremos trocar uma ideia!

Será um prazer!

E não esqueça que DDD é simplificar, é entregar valor pro seu cliente com uma solução altamente alinhada com a área de negócio dele.

Eu não entrei em muitos detalhes – e até várias outras disfunções encontradas quando falamos sobre DDD – mas ocasiões não irão faltar!

Com certeza. A gente se fala! Até mais e muito obrigado pelas dicas!

“Que isso”! Até!

Anúncios

8 comentários em “Um bate-papo sobre DDD

  1. Gostei do texto, parabéns!
    Se possível, gostaria que você falasse mais sobre este trecho:

    ” Por “time experiente”, entenda que seja um time onde haja, no mínimo, um líder que possa guiar o restante. Quanto maior e mais complexo o problema, mais necessária a presença de outros devs seniors. “

    1. Obrigado, Francisco.

      Cara, isso daria uma enorme conversa. Claro que não é possível opinar com mais detalhes sem um cenário real (o problema em mãos X o time disponível pra resolvê-lo), mas abaixo fica uma ideia geral:

      Acredito que problemas complexos precisam de pessoas experientes. Imagina um cenário, onde o cliente é novo, o negócio é complexo ou algo totalmente inédito pros desenvolvedores. Acho muito arriscado, um ato irresponsável, “jogar” um time só com caras iniciantes lá. É preciso, IMHO, que nesse time tenha alguém com mais experiência em desenvolvimento de software, que tenha uma visão mais estratégica, que pense antes de sair codando feito um louco, que possa orientar na tomada de decisões em relação à práticas e tecnologias (até mesmo para tirar um pouco o peso/pressão dos mais novos).
      Imagina um projeto de alto risco, formado só por programadores “porra-louca”, que leem um livro desses do Evans (ou de design patterns) e saem aplicando TUDO que está no livro porque achou legal?

      É mais ou menos isso que eu quis dizer…
      []s

      ps.: Todo dev já fez ou fará alguma coisa no impulso/loucura. O problema é quando ele nunca aprende com isso e continua sendo um “porra-louca”.

  2. Perfeito! Eu mesmo quero aprender mais sobre DDD, porém sei que me falta bagagem por isso estou lendo antes alguns livros (Clear Code, PPP, Gof, TDD etc). Tudo isso para me dar suporte para enfrentar o livro do Evans com mais propriedade. Vejo muita gente tratando software de modo imediato, querendo pular a fase de estudos e ir direto para prática. Isso é um reflexo de como levamos a maioria dos assuntos na superficialidade. Daqui uns tempos não me surpreenderia se alguém me perguntasse: “Aonde é que baixa esse framework de DDD mesmo?”.

    1. Cara, há alguns anos, assisti a uma palestra “sobre DDD” onde o palestrante mal falou de DDD, o foco da palestra foi promover o framework de DDD dele (tinha até um nome que eu não me lembro mais). Que eu me lembre, tinha uma porção de coisas pra “facilitar” como classes-base para repositório, entidades, etc, mas eu achei na época extremamente “over-projetado”. Nada contra criar libs pra facilitar nossa vida (facilitar de verdade) mas isso é outra história. O espírito do DDD não é esse.
      Manda bala nos estudos!

  3. Eu concordo em quase tudo. Hoje, há inúmeras pessoas que falam “DDD”, criam alguns materiais e tutoriais com algum CRUD dizendo usar “DDD” e por fim, vender seus treinamentos.rs

    Bom, na minha opinião, acho que o que mais encaixa em arquitetura de software (DDD,BBB,MIMIMI) não importa a sigla, é a sua seguinte frase:
    “DDD possui um conjunto grande de práticas, que servem para resolver um problema complexo.”

    Pois bem…Complexo, mas o que se define complexo? Usar um canhão pra matar uma formiga? Separar em “Bounded Context” (Inúmeras class library, dbcontext, etc) para um sistema de gestão empresarial para micro empresas?

    Eu não sou muito fã do “DDD” e das suas crenças, desenvolver software não é somente seguir um livro por Evan, ou qualquer outro autor.

    Deve-se aproveitar e entender todas as técnicas e patterns usados…E mesmo assim, não será a bala de prata.

    DDD é apenas “Moda” para muitos devs. E infelizmente essa “moda” caiu em cheios em projetos .net

    No mais, gostei da leitura, me fez prestar atenção nessa histórinha…Parabéns Robson

    1. Obrigado, Rodrigo.

      Qto ao DDD e a complexidade, ele te ajuda justamente a reduzir essa complexidade, quebrando um problema em nível empresarial em problemas menores. Assim você foca no mais complexo, no que é o cerne do negócio e deixa o resto (outros bounded contexts) para implementar de um jeito mais simples (meros CRUDs) ou até mesmo comprar uma solução pronta.

      O problema é não identificar esses contextos ou querer implementar todos eles com um alto grau de complexidade, o que muitas vezes é desnecessário ou até inviável pro negócio.

      As empresas acumulam uma série de softwares, alguns poucos usados, outros com features duplicadas, justamente porque não tiveram a preocupação estratégica ao pensar na solução.

      []s

  4. Ótimo texto Robson! Estou estudando o livro do Eric nesse momento, e é muito bacana encontrar posts assim como o seu para sanar algumas dúvidas. O livro realmente se torna bastante abstrato em alguns pontos. Provavelmente vou ler algum livro mais focado na implementação depois desse.

    Gostei bastante do formato também. O Uncle Bob costuma escrever posts assim, nesse formato de diálogo, e é bastante interessante como forma do autor se colocar no lugar do leitor, para quem aquelas informações talvez sejam bem novas e não façam muito sentido.

Participe! Vamos trocar uma ideia sobre desenvolvimento de software!

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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s