Domain-Driven Design (DDD) é uma abordagem para desenvolvimento de software que estabelece forte ligação entre implementação e modelo de negócios. DDD fornece estrutura de práticas e terminologia para tomada de decisões de design, focando em acelerar projetos de software e alinhar com domínios de negócio. DDD utiliza conceitos como modelagem orientada a domínio, arquitetura em camadas, entidades, value objects, aggregates, services e repositories.

1. Domain-Driven Design Uma Abordagem Introdutória

2. Apresentações Armênio Cardoso Consultor, Arquiteto de Sistemas e Professor http://www. linkedin .com/in/ armeniocardoso http://www. slideshare .net/ armeniocardoso

3. Reflexões Quanto mais simples algo é, mais fácil é o seu entendimento . Quanto mais complexo algo é, mais difícil é o seu entendimento . Quanto menos você entende algo, mais difícil é consertá-lo ou modificá-lo. Conclusão : quanto mais complexo um sistema fica, mais difícil e caro é mantê-lo. Max Kanat-Alexander, Code Simplicity.

4. Reflexões O Desejo de construir um software é diretamente proporcional ao seu Valor e inversamente proporcional ao Esforço dedicado a desenvolvê-lo. D = (Vn + Vf) / (Ei + Em) Max Kanat-Alexander, Code Simplicity. Vi = Valor de Implementação Vf = Valor Futuro Ei = Esforço de Implementação Em = Esforço de Manutenção

5. Reflexões Nossa Missão Desenvolver sistemas que... ...tenham o máximo de Valor ... ...com o mínimo de Esforço de desenvolvimento.

6. Reflexões Cada vez mais as pessoas parecem confundir complexidade com sofisticação. O incompreensível deveria causar suspeita e não admiração. Possivelmente, esta tendência resulta de uma crença errônea de que o uso de mistério confere uma aura de poder. Niklaus Wirth, “pai” da Linguagem Pascal.

7. Definições Domain-Driven Design é uma abordagem para o Desenvolvimento de Software que estabelece uma forte ligação entre a implementação e o modelo evolutivo dos conceitos de negócio. Implementação X Negócios

8. Definições Domain-Driven Design não é uma tecnologia ou uma metodologia. DDD fornece uma estrutura de práticas e terminologia para a tomada de decisões de design. O foco é acelerar os projetos de software e alinhar com os domínios de negócio.

9. Definições Domínio A esfera do conhecimento, influência ou atividade de negócio. A área de negócio que será abordada pelo projeto de software. Modelo Um sistema de abstrações que descreve aspectos selecionados de um domínio com o objetivo de resolver problemas de negócio.

10. Definições Idioma onipresente (ubiquitous) Uma linguagem estruturada em torno do modelo de domínio e usado por todos os membros da equipe para conectar todas as atividades da equipe com o software. Contexto A situação onde uma palavra ou declaração aparece, determinando o seu significado.

11. Peças do DDD Model-Driven Design Layered Architecture

12. Arquitetura em Camadas

13. Arquitetura em Camadas User Interface : responsável pela apresentação das informações e interpretação das interações dos usuários. Application Layer : coordena as atividades da aplicação. Domain Layer : contém os componentes de negócio – é o centro da aplicação. Infraestructure Layer : provê o suporte para as outras camadas, bibliotecas, persistência etc.

14. Peças do DDD Entities

15. Peças do DDD Entities Entidades derivam objetos com identidade, distinção e continuidade (ciclo de vida). Entidades podem ter atributos alterados sem que a identidade do objeto seja afetada. Entidades contém métodos de negócio que implementam regras que se aplicam ao objeto em questão. Pessoa, Aluno, Professor, Nota-fiscal.

16. Peças do DDD Value Objects

17. Peças do DDD Value Objects Value Object é um tipo de objeto que é imutável e não tem identidade. Value Object deriva objetos que são definidos pelos seus atributos e por isso são imutáveis. Objetos de valor não têm métodos de negócio. Endereço, Itens da Nota-Fiscal, Unidade da Federação, Estado Civil, Usuário (login e senha).

18. Peças do DDD Aggregates

19. Peças do DDD Aggregates É uma Entidade composta por outros objetos (Entities e/ou Value Object) vista como uma unidade. Essa Entidade é denominada de Raiz da Agregação. A raiz de agregação garante a consistência das mudanças que são feitas dentro do agregado, impedindo que objetos externos realizem referências a seus membros. Nota-Fiscal é um agregado que contém Itens de Nota-Fiscal. Cliente é um agregado que contém Endereços.

20. Peças do DDD Services

21. Peças do DDD Services Quando uma operação de negócio não pertence conceitualmente a um único objeto esta reside em um Service. Services têm uma ligação estreita com os casos de uso modelados no sistema. Services não têm estado. A classe SecretariaService contém um método matricularAluno que recebe Aluno e Turma como parâmetros.

22. Peças do DDD Services A Camada de Serviço define os limites de uma aplicação e seu conjunto de operações disponíveis a partir da perspectiva do cliente. Ela encapsula a lógica de negócios, transações e coordenação das respostas na implementação de suas operações. http://martinfowler.com/eaaCatalog/serviceLayer.html

23. Peças do DDD Factories

24. Peças do DDD Factories Métodos para criar objetos de domínio complexos devem delegar a objetos de fábrica especializados, de forma que as implementações possam ser facilmente mantidas. São úteis na criação de Aggregates.

25. Peças do DDD Repositories

26. Peças do DDD Repositories Um repositório é um mecanismo para encapsular o armazenamento, recuperação e comportamento de busca, que emula uma coleção de objetos. Para cada tipo de objeto que precisa de acesso global, criar um Repositório que pode fornecer a ilusão de uma coleção em memória de todos os objetos desse tipo.

27. Critérios de Sucesso Use DDD se O seu domínio não é trivial. A equipe de desenvolvimento tem experiência e interesse em OOP/OOD. Existe o acesso aos detentores das informações sobre o domínio. O processo de desenvolvimento é iterativo.

28. Critérios de Sucesso Domain-Driven Design é um tema muito amplo e contém muitas coisas que são difíceis ou impossíveis de incorporar no código de um aplicativo simples. Coisas a se destacar Comunicação com o especialista de domínio. Modelagem iterativa. Descoberta de uma linguagem onipresente.

29. Perguntas? e Obrigado!