O documento discute a implementação do Domain-driven Design (DDD) com o framework Rails. Apresenta os desafios de vincular um sistema ao framework, como manter o código representando fielmente o domínio. Explica conceitos do DDD como entidades, agregações, repositórios e serviços. Discutiu os desafios de separar o domínio dos modelos Rails e organizar o código em bounded contexts de acordo com os comportamentos.

1. F r e v o o n R a i l s - a b r i l / 1 6
DDD E RAILS
Implementando Domain-driven Design com Rails:
Um caso de sucesso.
Marcelo Theodoro

2. AGENDA
▫︎O domínio do Capcom
▫︎O problema em utilizar frameworks
▫︎Domain-driven Design
▫︎Desafios que encontramos
2

3. O DOMÍNIO DO CAPCOM
3

4. 4
Frameworks tem sua própria agenda e
suas próprias prioridades. Ao vincular
sua aplicação a um framework, você
está sujeito às mudanças do
framework.
Uncle Bob

5. 5
O código de um sistema deve ser uma
representação fiel do domínio. Se o seu
código está dentro do Rails (ou de
qualquer MVC), ele não está
representando o domínio.

6. QUE AÇÕES O DOMÍNIO DE AMORTIZAÇÕES FAZ?
6
Qual parece mais adequado?

7. DOMAIN-DRIVEN DESIGN
Uma abordagem para desenvolvimento de
softwares complexos
Reune um conjunto de boas práticas, padrões de projeto, conceitos de SOLID e
introduz uma linguagem ubíqua.
Domínio é uma área de conhecimento do negócio onde o software está
inserido.
Uma linguagem comum entre negócio e
desenvolvimento
■ Todas as pessoas dentro de um time falando a mesma língua
■ Sem tradução: ”o que o cliente chama de custo é o campo valor”
7

8. DDD - ABORDAGEM
Foco no domínio principal
Explore os modelos em conjunto com
desenvolvedores e especialistas de domínio
Converse em uma linguagem comum dentro
de um contexto específico
8

9. DOMAIN-DRIVEN DESIGN
9

10. 10
Expresse o domínio e a lógica de
negócio, eliminando a dependência
com a UI, infra-estrutura e código não
relacionado ao domínio.

11. 11
Separe o sistema em camadas,
mantendo a coesão e criando
dependência somente com as camadas
inferiores

12. ARQUITETURA EM CEBOLA
12

13. ENTIDADES
Um objeto distinto pela sua identidade
■ Um produto em uma loja
■ Uma nota fiscal na contabilidade
■ Uma pessoa para o governo
- E por aí vai…
13

14. OBJETOS DE VALOR
Um objeto cuja identidade não importa
Só tem importância pelos seus atributos ou por sua lógica
É um objeto imutável
■ Uma cor
■ Uma descrição
■ Uma data ou hora
■ Um endereço
- E por aí vai…
14

15. AGREGAÇÕES
Uma combinação entre entidades e seus
relacionamentos com objetos de valor
dentro de um contexto
Uma agregação é tratada como uma única unidade.
Só é acessada pela sua raíz, uma entidade.
■ Pedido (itens, local de entrega, cliente, cupom de desconto)
■ Chamado/Atendimento (atendente, hora, local, comentários, tags)
- E por aí vai
15

16. AGREGAÇÕES
16

17. FACTORIES
Responsável por
criar instâncias
de objetos
complexos ou
agregações
17

18. REPOSITÓRIOS
Responsável por buscar informações de
dependências externas ao domínio
Banco de dados, APIs, Arquivos, Sockets…
18

19. REPOSITÓRIOS
19

20. SERVIÇOS
Encapsula
operações ou
processos de
negócio
20

21. BOUNDED CONTEXT
Subsistemas/subdomínios que representam
contextos específicos e bem definidos.
21
Fonte: http://martinfowler.com/bliki/BoundedContext.html

22. BOUNDED CONTEXT
22

23. BOUNDED CONTEXT
23

24. DESAFIOS
Separar as entidades de domínio dos Rails
Models: Repositórios e Adaptadores
24

25. DESAFIOS
25

26. BOUNDED CONTEXT
26
Organizar o código dentro de um bounded
context? Por comportamentos.

27. DESAFIOS
Criar visões que tocam várias partes do
domínio: Views
27

28. DESAFIOS
28

29. DESAFIOS
Refatorações para manter o codebase
coerente com o conhecimento do domínio
Ater-se as disciplinas do DDD
29

30. Perguntas?
Marcelo Theodoro
marcelo.theodorojr@gmail.com
MUITO OBRIGADO