Treinamento DDD com foco em .Net para fabrica de software em Julho de 2013

1. DDD
@henriquericcio

2. Antes de mais nada
Revisitando conceitos e princípios.

3. Layers
É uma forma de agrupar elementos que
possuem uma mesma responsabilidade.
Ex.:
Camada de Dados
Camada de Lógica de Negócio
Camada de Integração

4. Modelo
É aquilo que abstrai e expressa algo.
Ex.:
● Modelo matemático;
● Planta de edifícios;
● Modelo de domínio;
Modelar é importante, pois viabiliza a
transmissão de informações sobre o assunto.

5. Uncle Bob
Robert C. Martin
Escreveu diversos livros e artigos sobre OOP.
E aprensentou os seguintes princípios:
● ISP - Interface Segregation Principle
● SRP - Single Responsability Principle
● DIP - Dependency Inversion Principle

6. "Clientes não devem ser forçados a depender
de interfaces que eles não usam"
ISP

7. SRP
"Uma classe deve ter apenas uma simples
responsabilidade"

8. DIP
"algo deve depender de abstrações e não de
implementações."

9. Design Patterns
Design Patterns: Elements
of Reusable Object-Oriented
Software é um livro de
engenharia de software que
descreve soluções
recorrentes para problemas
comuns na modelagem de
software.

10. Factory Method
Um pattern criacional, responsável por abstrair
o processo de criação de objetos complexos.

11. P of EAA
Um livro sobre design
de software orientado
a objeto escrito por
Martin Fowler e
Colaboradores, no
qual abordou diversos
padrões.

12. Repository
Mediador entre o domínio e as camadas de mapeamento
de objeto, usando uma interface do estilo de coleção, para
acessar objetos de domínio.

13. Service Layer
Define um limite de
aplicação com uma camada
de serviços que estabelece
um grupo de operações
disponíveis e coordena a
resposta da aplicação para
cada operação.

14. Value Object
Um pequeno e simples objeto, como money ou
date range, cuja igualdade não é baseada na
identidade, mas sim nos valores de seus
atributos.

15. Data Transfer Object
Um objeto que transfere dados entre processos
com o intuíto de reduzir o número de
chamadas ao método.

16. Separated Interface
Define uma interface
em um pacote
separado de sua
implementação.

17. Remote Facade
Provê uma fachada, de baixa granularidade, para acesso
de objetos altamente granulares no intuito de melhorar a
eficiência de transmissão de rede.

18. Domain Model
Um modelo de objetos
do domínio que
incorpora
comportamento e
dados.

19. Agora sim...
Vamos comecar a falar de DDD.

20. Domain-Driven Design
Modelagem orientada ao domínio
Erick Evans lançou em 2003 o
“Domain-Driven Design: Tackling
Complexity in the Heart of
Software”.

21. Mas o que é?
Uma compilação de práticas para criação de
softwares que expressem as necessidades de
negócio através do modelo de domínio.

22. Layered Architecture
O Domain Layer deve ser
o mais isolado possível.
Usar DI ajuda!!!

23. User Interface Layer
Responsável por apresentar informação para o
usuário e interpretar seus comandos.
User Interface não é necessariamente uma
tela!

24. Application Layer
Uma fina camada que coordena a atividade da
aplicação. Ela não contem regra de negócio,
não mantém estado dos objetos de negócio,
mas pode manter o estado de uma tarefa da
aplicação.

25. Domain Layer
Esta camada contém informação sobre o
domínio. Este é o coração do software.O
estado dos objetos é mantido aqui.
Persistência dos objetos de negócio e
possivelmente seu estado são delegados à
camada de infraestrutura.

26. Infrastructure Layer
Esta camada age como uma biblioteca de
suporte para todas as outras camadas. Ela
provê comunicação entre camadas,
implementa persistência para objetos de
negócio, contem bibliotecas de suporte para a
camada de interface, etc

27. Domain Patterns
O DDD define o uso de alguns padrões para
modelagem de domínio:
● Repository
● Domain Service
● Factories
● Entities
● Value Objects
● Aggregates

28. Entity
● Possui uma identidade;
● Implementadas como
POCO's (POJO's);
● Métodos fortes (negócio);
● Constructor com a
identidade;

29. Value Object
● Imutáveis;
● Reconhecidos pelos seus
atributos;
● Constructor define o valor de
todos os atributos do objeto;

30. Domain Services
É a representação de serviços oferecidos ao
domínio. Todo comportamento que não pode
ser de responsabilidade de uma entidade, é
representado desta forma.

31. Factories
● Para criação de entidades;
● Encapsula a complexidade de criação;

32. Repositories
Representa, no domínio, a persistência da
entidade, que pode ser efetivamente realizada
em banco de dados, arquivo, ou até integração
com outro sistema.

33. Aggregates
Objetos se associam, uns aos outros, criando
relações complexas.
Dentre os objetos de uma relação, um possuí
maior expressão (naquele contexto).
Ex.: Conta Corrente e Lançamento

34. Ubiquotous Language
Traduzindo, “Linguagem Onipresente”, é a que
está em todo lugar. É a linguagem de quem
entende do negócio.
É uma forma de todos falarem a mesma língua,
a língua do negócio (Domínio).

35. Bounded Context

36. Continuous Refactoring
Refactoring do modelo!
Se a compreensão do problema mudou,
refatore!

37. Quando usar?
Quando o projeto envolve regras complexas
como processamento de uma fatura de cartão
de crédito.

38. Recursos
Livro Patterns of Enterprise Application Architecture - Martin Fowler
http://martinfowler.com/books/eaa.html
Princípios de Design OO - Uncle Bob
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Design Patterns: Elements of Reusable Object-Oriented Software (material oficial)
http://c2.com/cgi/wiki?DesignPatternsBook
Design patterns e exemplos em C#
http://www.dofactory.com/Patterns/Patterns.aspx
E-book gratuíto sobre DDD
http://www.infoq.com/minibooks/domain-driven-design-quickly
O livro do Eric Evans
http://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20
Exemplo em C# usado para esse treinamento
https://github.com/henriquericcio/ExemploDDD