O documento discute os principais conceitos do Domain-Driven Design (DDD) e erros comuns na sua aplicação, como implementar toda a arquitetura e padrões sem necessidade ou usar termos diferentes para os mesmos conceitos do negócio. Também aborda quando o DDD deve e não deve ser utilizado.

1. Domain Driven-Design
Pensando Fora da Caixa
Thiago Bertuzzi

2. It´s-a me Bertuzzi
• Thiago Bertuzzi é desenvolvedor .net há 15 anos participando
de projetos Desktop, Services, Web e Mobile utilizando
Xamarin.
• É Microsoft MVP em Developer Technologies
• É Líder técnico / Arquiteto Mobile e .Net na NESS
• Contribui para comunidade Xamarin escrevendo artigos,
compartilhando códigos, palestrando e criando pacotes Nuget.

3. O que é Domain-Driven Design (DDD)?
• DDD
• Desenvolvimento guiado pelo domínio
• É uma abordagem de modelagem de software destinada para
auxiliar no tratamento de regras e resolução de problemas
complexos do negócio.

4. O que é Domain-Driven Design (DDD)?
Idealizado por Eric
Evans, no famoso “Blue
book”
Domain-Driven Design
Atacando as
complexidades no
coração do software

5. Disclaimer
• Sou a favor da utilização consciente!
• DDD é uma abordagem valiosa e por isso deve ser usada com
propósito!
• Essa palestra trata de erros comuns na escolha dessa abordagem,
motivadas pela falta de conhecimento real sobre o assunto.

6. Mas que erros?

7. Vou construir meu projeto com uma
arquitetura DDD!

8. X
Design

9. Arquitetura

10. Arquitetura
É o planejamento da solução,
contendo a definição dos
componentes e a interação entre
eles

11. Design

12. Design
É a forma (padrões e práticas)
como os componentes são
implementados

13. Na minha empresa de prestação de
serviços, o time de negócio se refere ao
serviço realizado como “Produto”, mas no
meu código, vou chamá-lo de “Serviço”
mesmo.

14. Linguagem Ubíqua

15. Há diversas áreas na minha empresa, mas eles
falam sobre o Cliente de forma diferente e
alguns requisitos e regras de uma área são
diferentes da outra área. Vou mesclar as
necessidades e resolver de uma vez só!

16. Bounded Contexts (Contextos Delimitados)

17. Big Ball of Mud (Grande bola de lama)

18. •Vou começar a implementar o meu
projeto com DDD, usando um template e
criando todas as camadas e patterns

19. Modelagem Tática
• Lembre-se, DDD antes de tudo é sobre resolver problemas do negócio. Ele
que vai demandar o que você precisa ou não;
• Os patterns não são específicos do DDD, mas foram agrupados para compor
essa abordagem. Não utilizar todos eles, não significa abandonar o conceito;
• Cuidado ao criar complexidade desnecessária. Não implemente padrões ou
camadas que não fazem sentido para o seu cenário;
• Templates de demonstração dessas abordagens são válidos para estudar e
compreender, porém não deve ser replicado em produção (Copia-Cola).

20. Representação

21. Representação

22. Quando devo utilizar o DDD?
• Cenários onde o negócio por si só já é complexo;
• Quando há granularidade e complexidade das regras de negócio;
• Quando as suas necessidades estão centradas nas operações do
negócio e não exclusivamente em dados;
• Você possui diversos contextos que por mais que funcionem
independentemente, precisam compartilhar informações entre si.

23. Quando não devo utilizar o DDD?
• Quando sua aplicação é centrada em dados (aplicações contendo
apenas CRUDs) ou regras simples;
• Apenas pelo desejo de adotar a abordagem na aplicação, mesmo
ela sendo simples;
• Quando não se tem conhecimento do negócio. Essa análise
devera ser feita com um Domain Expert;
• Se você não tem ampla compreensão do que é e o que não é
DDD.

24. Livros Recomendados

25. Obrigado / Duvidas?
• “Toda vez que alguém fala “Vou construir meu projeto com uma
arquitetura DDD”,Deus mata um panda”
• twitter.com/tbertuzzi
• github.com/tbertuzzi
• nuget.org/profiles/Bertuzzi
• medium.com/@bertuzzi
• bertuzzi.dev