1. Rodrigo Branas - @rodrigobranas – http://www.agilecode.com.br
Domain-Driven Design

2. http://www.slideshare.net/rodrigobranas

3. @rodrigobranas
rodrigo.branas@gmail.com
http://www.agilecode.com.br
Formação Acadêmica
Ciências da Computação – UFSC
Gerenciamento de Projetos - FGV
Certificações
SCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM

4. Rodrigo Branas – rodrigo.branas@gmail.com
10 anos de experiência na plataforma Java
1000 horas em sala de aula
Mais de 50 palestras em eventos
Líder da área de desenvolvimento na Gennera
Autor da revista Java Magazine
Palestrante
Instrutor da Academia Java e Agile da Globalcode
Criador dos treinamentos de Clean Code, Selenium e
Maven da Agile Code
Trabalhou com as empresas:
EDS, HP, GM, Citibank, OnCast, Globalcode, V.Office, Dígitr
o, Softplan, Unimed, Suntech, Vale do Rio

5. Software é uma abstração da
realidade

6. A realidade é formada por
conhecimento tácito

7. Conhecimento Tácito
“Conhecimento formado no dia-a-dia
das pessoas, intangível e difícil de
ser descrito através de palavras.”
Exemplos: Dirigir, Tocar um instrumento
musical, Praticar um esporte.

8. Esse conhecimento é
denominado de Domain

9. Domain
“Campo de ação, conhecimento e
influência.”
É completamente abstrato e
intangível inicialmente

10. Cuidado: Domain não é um
diagrama ou algo do tipo

11. Domain Model

12. Estruturar, organizar e esclarecer
o Domain

13. Sua principal importância está
no feedback

14. Cuidado: Também não é um
diagrama ou algo do tipo

15. Domain Model é a idéia que o
diagrama tenta transmitir

16. O conhecimento está na cabeça
dos Domain Experts

17. Domain Experts

18. Quem é o Domain Expert?

19. Alguém que conhece profundamente
os detalhes de um Domain

20. O que diferencia um Domain
Expert de um Product Owner?

21. Distância entre Domain Experts
e desenvolvedores

22. Cuidado: Problemas de
comunicação pela frente!

23. Aprendizagem do Domain

24. Você já teve a sensação de estar
perdido em um projeto?

25. Como começar?

26. Não entre em detalhes, crie uma
definição superficial e abrangente do
escopo do projeto e a utilize como
base para continuar evoluindo rumo a
um entendimento completo e
profundo.

27. Problemas de falta de contexto

28. Montando o quebra-cabeça com
apenas um pedaço do mapa

29. Cuidado: Tentar entender apenas
uma pequena parte do todo, em
detalhes, pode ser complicado

30. Nunca vá a frente sem entender
tudo que é discutido e conversado

31. Linguagem e Comunicação

32. Convivemos em tribos
diferentes

33. Por conta disso, utilizamos de
linguagens muito diferentes

34. Domain Experts tem dificuldade
em entender de tecnologia

35. Cuidado: Não imponha uma
linguagem focada na tecnologia

36. É muito importante criar e estabelecer
uma linguagem oficial, entendida por
Domain Experts e desenvolvedores

37. Ubiquitous Language

38. A linguagem é o conhecimento
de forma dinâmica

39. Deve ser utilizada todo o tempo
no decorrer do projeto

41. Debate: Utilizar inglês ou
português dentro do código?

42. Diagramas

43. Existe algum diagrama específico
para trabalhar com Domain-Driven
Design?

45. Facilitando a comunicação e
melhorando o aprendizado

46. Breakthrough

47. Model-Driven Design

48. O que é o Design de um
software?

49. Cuidado: Design não é relacionado
as cores utilizadas na interface gráfica

50. Qual é a diferença entre o Design
e a Arquitetura de um software?

51. O código deve
refletir a
linguagem

52. Isolando e fortalecendo o
Domain Model

54. Smart UI

55. Produtividade parece ser alta no início

56. Desvantagens:
1. Não é reutilizável
2. Pouco flexível
3. Dificilmente integrável
4. Ambiente torna-se caótico
rapidamente

57. Arquitetura
em camadas

58. User Interface

59. Camada responsável por
abrigar ações e comandos
capazes de interpretar ações
realizadas por usuários.
(Inclusive outro sistema)

60. Application

61. Camada responsável por
suportar diversos tipos de UI,
realizar traduções e conversões
de dados e ainda exposição das
operações de negócios para
quem tiver interesse
na aplicação

62. Domain

63. Camada onde os artefatos
expressam o domínio. Essa
camada é onde fica o coração
do software. Deve refletir o
Domain Model.

64. Infrastructure

65. Suporte técnico para as outras
camadas. Responsável pela
persistência, segurança, e
auditoria.

66. Domain Objects

67. Entity

68. Cuidado: O conceitos de ORM
sobre entidades é diferente

69. Possuem uma identidade
dentro do domínio

70. Value Object

71. Não tem identidade

72. Exemplo: Cor RGB
Public class RGBColor {
public int red;
public int green;
public int blue;
public RGBColor(int red, int green, int blue) {
this.red = red;
this.green = green;
this.blue = blue;
}
}

73. Representam valores imutáveis

74. Service

75. Services são objetos que
gerenciam a execução de fluxos
de negócio orquestrando a
interação entre os objetos do
domínio

76. Cuidado: Modelo Anêmico

77. Services em geral não possuem
estado

78. Entendendo SOA
Service-Oriented Architecture

80. Isolando conceitos

81. Aggregates

82. Grupo lógico de objetos

84. Uma entity deve ser a raiz e
único ponto de acesso

85. Entendendo o ciclo de vida
dos Domain Objects

86. Factory

87. Facilitar e assumi a
responsabilidade pela criação
de objetos, ocultando a
complexidade.

88. Tipos de Factory

89. Simple Factory

90. Factory Method

92. Abstract Factory

94. Repository

95. Guardando e recuperando
Domain Objects

96. Faz uso da camada de
infraestrutura

97. Repository não é parecido com
o padrão DAO?

99. Supple Design

100. Aumentando a expressão do
Domain no código

101. Intention revealing interfaces

102. Interface Implementação

103. Side-effect free functions

104. Métodos que realizam
consultas (Queries) e possuem
retorno, no entanto modificam
o estado de objetos
(Comandos)

105. Assertions

106. Contorno conceitual

107. Qual é a precisão da
abstração?

108. Classes independentes

109. Voltando as raízes da
Orientação a Objetos

110. Coesão

111. A importância da
responsabilidade única

112. Acoplamento

113. Lei de Demeter

114. Strategic Design

115. Modularizando sistemas
grandes e complexos

116. Trabalhar com equipes
externas

118. Bounded Context

120. Domain Models diferentes

121. Redução do acoplamento

122. Como fica o reuso?

123. Continuous Integration

125. Integrando diferentes
contextos

126. Cuidado: Contextos individuais
podem deixar de funcionar em
conjunto

127. Context Map

128. Visualizar o todo

129. Descrição de cada ponto de
contato entre os modelos de
cada contexto

131. Exercício: Criar o Context Map
para o Domain Model.

133. Shared Kernel

134. Quando dois times alteram uma mesma base de
código comum. É importante que esse pedaço
de código esteja bem definido e que possua
muitos testes automatizados, que devem ser
rodados por qualquer um dos grupos que
desejar fazer alguma alteração.

136. Cuidado: Comunicar a outra
equipe sempre que for realizar
qualquer alteração

137. Customer/Suplier Teams

138. Contextos tecnologicamente
diferentes, tornando inviável a
utilização do Shared Kernel

139. Uma equipe fará o papel de
consumidora e a outra de
fornecedora

140. Conformist

141. A outra equipe não está
interessada em colaborar

142. Como resultado temos um
Shared Kernel sem colaboração

143. Separate Ways

144. O trabalho para integrar é tão
grande que vale mais a pena
seguir por um caminho
separado

145. Open Host Service

146. API consumida como serviço
externo através de protocolos
de rede

147. Published API

148. Documentando e orientando a
utilização da API

149. Anticorruption Layer

150. Quando temos um sistema legado, com código
muito bagunçado e uma interface complexa, e
estamos escrevendo um sistema novo com o
código razoavelmente bem feito, criamos uma
camada entre esses dois sistemas .
O nosso sistema novo e bem feito falará com essa
camada, que possui uma interface bem feita. E a
camada anti-corrupção é responsável por traduzir
e adaptar as chamadas para o sistema legado,
usando uma fachada interna.

152. “Any fool can write code that a
computer can understand.
Good programmers write code
that humans can understand.”
Martin Fowler