Encontrando o equilíbrio do DDD enquanto sua aplicação cresce

Transcript

1. Olá, pessoal!
2. @carolkarklis Desenvolvedora de software na Magnetis Ruby e Elixir ❤ Gatos Comunidade Diversidade e inclusão ‍♀
7. https://magnetis.workable.com
8. https://astro.magnetis.com.br/
9. 01 Visão geral de Domain Driven Design (DDD) agenda 02 Por quê usar DDD? 03 Começando com DDD 04 Abordagens para cada cenário @carolkarklis
10. A motivação por trás dessa talk veio de um outro evento de tecnologia Photo by James Pond on Unsplash @carolkarklis
11. Quando será que é o momento certo de prestar mais atenção no código e na arquitetura?
12. Qual o equilíbrio do desenvolvimento de software?
13. Go horse O equilíbrio O equilíbrio no código Overengineering
14. O objetivo da talk ▪ Entender o básico do que é DDD ▪ Conseguir identificar o momento atual da empresa ▪ Qual a melhor abordagem pro atual momento (técnica ou não técnica) ▪ Inspirar e incentivar a visão de trazer valor pro negócio através do código @carolkarklis
15. Visão geral sobre DDD
16. DDD significa Domain Driven Design Ou Projeto Orientado a Domínio
17. O domínio do negócio guia o desenvolvimento do projeto
18. Domínio é um conjunto de coisas que uma empresa faz para resolver um problema
19. Sistema e-commerce
20. Sistema e-commerce Domínio
21. Sistema e-commerce Domínio
22. A linguagem ubíqua É um dos pilares do Domain Driven Design
23. O que não é ▪ A linguagem do negócio (jargões, termos, etc) Photo by Hans-Peter Gauster on Unsplash
24. O que não é ▪ A linguagem do negócio (jargões, termos, etc) ▪ Comunicação feita pelos especialistas do domínio Photo by Hans-Peter Gauster on Unsplash
25. O que não é ▪ A linguagem do negócio (jargões, termos, etc) ▪ Comunicação feita pelos especialistas do domínio ▪ Um jeito de nomear coisas no código Photo by Hans-Peter Gauster on Unsplash
26. O que não é ▪ A linguagem do negócio (jargões, termos, etc) ▪ Comunicação feita pelos especialistas do domínio ▪ Um jeito de nomear coisas no código ▪ A forma que desenvolvedores se comunicam sobre o sistema Photo by Hans-Peter Gauster on Unsplash
27. O que não é ▪ A linguagem do negócio (jargões, termos, etc) ▪ Comunicação feita pelos especialistas do domínio ▪ Um jeito de nomear coisas no código ▪ A forma que desenvolvedores se comunicam sobre o sistema ▪ Comunicação sobre as coisas que o sistema deveria fazer Photo by Hans-Peter Gauster on Unsplash
28. "A prática de construir uma linguagem rigorosa, geral entre desenvolvedores e usuários" Eric Evans
29. A linguagem ubíqua Ela é baseada no modelo do domínio e expressa como o sistema funciona de uma forma compreensível para o time inteiro É uma linguagem sobre o conhecimento compartilhado do domínio feita pelo time
30. Criar um ambiente com essa linguagem é essencial para a evolução do código
31. Código que expressa o que o domínio faz
32. "Ao implementar DDD, é esperado que o design do código seja questionado" Vaughn Vernon, no livro Implementing Domain-Driven Design
33. Por quê usar DDD? (ou como convencer seu time a dedicar tempo nessa prática)
34. Photo by Benjamin Behre on Unsplash Diminuição da ilha de conhecimento
35. Photo by NeONBRAND on Unsplash Uma definição precisa e compreensível do negócio sendo desenvolvido
36. Photo by Sabine Peters on Unsplash Manutenção do código fica mais fácil e menos custosa
37. Photo by Brad Barmore on Unsplash Modelagem contínua do sistema
38. Photo by NESA by Makers on Unsplash Desenvolvimento mais eficiente pelo uso da linguagem ubíqua
39. Eu acredito que todos podem se beneficiar do uso do DDD
40. Mas o investimento em DDD vai depender do cenário da empresa
41. Investimentos levam tempo A definição de investimentos é aplicar recurso, tempo e esforço com a finalidade de obter algo depois. Você deve considerar se o time está disposto a investir em construir um software melhor.
44. Design Stamina Hypothesis Martin Fowler
46. Nesse ponto, você vai ter que abrir mão de qualidade por tempo
48. Qual o cenário do seu sistema hoje?
49. afirmação O sistema é completamente guiado por dados e você pode classificá-lo como uma solução CRUD (create, read, update, delete). Seu time apenas precisa de uma interface bonita para manipular os dados. Cenário #1
50. afirmação O sistema é completamente guiado por dados e você pode classificá-lo como uma solução CRUD (create, read, update, delete). Seu time apenas precisa de uma interface bonita para manipular os dados. Cenário #1 diagnóstico Você não precisa de investir tempo e esforço do seu time para usar DDD. Isso não significa que você não deve se preocupar com a qualidade do código.
51. afirmação O sistema requer apenas 30 ou menos operações de negócio, é provavelmente bem simples de ter uma visão geral do sistema. Isso significa que a sua aplicação não tem mais do que 30 casos de uso (métodos), e cada um deles tem regras de negócio mínimas. Por isso, você não sente falta de controle pela complexidade do negócio. Esse cenário é comum para startups fazendo o MVP. Cenário #2
52. afirmação O sistema requer apenas 30 ou menos operações de negócio, é provavelmente bem simples de ter uma visão geral do sistema. Isso significa que a sua aplicação não tem mais do que 30 casos de uso (métodos), e cada um deles tem regras de negócio mínimas. Por isso, você não sente falta de controle pela complexidade do negócio. Esse cenário é comum para startups fazendo o MVP. Cenário #2 diagnóstico Você pode até ter um desafio em mente, mas usar DDD agora é um custo alto porque você não sentiu a dor da complexidade ainda. Talvez seja o momento de se juntar com os especialistas do domínio e evoluir a linguagem ubíqua.
53. O que você pode fazer ▪ Evoluir a linguagem ubíqua ▪ Utilizar uma ferramenta que analise o código (rubocop, por exemplo) ▪ Fazer uma bagunça organizada ▪ Acompanhar métricas de software como Churn vs Complexity
54. como começar a construir a linguagem ubíqua
55. Junte-se com especialistas do domínio para conversar
56. Crie um glossário dos termos que chamam a sua atenção Photo by You X Ventures on Unsplash
57. Tente encontrar um conhecimento em comum
58. Documente o fluxo do ponto de vista de produto e do técnico
59. Utilize ferramentas para analisar o código
61. Acompanhar métricas de software Churn vs Complexity
62. Churn É uma medida sobre com que frequência um arquivo muda. Arquivos que mudam mais tem um churn maior
63. Complexity Geralmente é feito o cálculo da Cyclomatic Complexity, que calcula a quantidade de caminhos independentes o código têm (transferências de controle, sequências lógicas, etc)
65. ☠
66. ☠
67. Fazer uma bagunça organizada Talk da Sandi Metz "Go ahead, make a mess"
69. "É através do design de OO que você para de se preocupar e aprende a amar a bagunça" Sandi Metz, na talk "Go ahead, make a mess"
70. Sandi Metz
71. Sandi Metz
72. API pública Sandi Metz
73. API pública Sandi Metz exponha
74. API pública Sandi Metz exponha Comportamento privado
75. API pública Sandi Metz exponha Comportamento privado esconda
76. API pública Sandi Metz exponha Comportamento privado esconda Dependências Dependências
77. API pública Sandi Metz exponha Comportamento privado esconda Dependências Dependências minimize
78. API pública Sandi Metz exponha Comportamento privado esconda Dependências Dependências minimize mova
79. Nesse ponto, você vai ter que abrir mão de qualidade por tempo
80. "Qual o custo futuro de não fazer nada agora?" Sandi Metz, na talk "Go ahead, make a mess"
81. afirmação Digamos que você passou de 30 para 40 features e você está começando a questionar a complexidade das coisas que precisam ser feitas. O sistema talvez não seja mantido por um único time, mas outros times multidisciplinares. Você está pensativo sobre a evolução de produto dentro de cada time, e se é possível manter o sistema estável em qualidade de código e arquitetura. Cenário #3
82. afirmação Digamos que você passou de 30 para 40 features e você está começando a questionar a complexidade das coisas que precisam ser feitas. O sistema talvez não seja mantido por um único time, mas outros times multidisciplinares. Você está pensativo sobre a evolução de produto dentro de cada time, e se é possível manter o sistema estável em qualidade de código e arquitetura. Cenário #3 diagnóstico Você está chegando perto do ponto onde existe um real benefício em fazer design de código: O benefício da produtividade e ser feliz. Você e seu time deveriam começar a falar sobre design de código (inclusive DDD).
83. O que você pode fazer ▪ Se possível, fazer com que cada time tenha pelo menos uma pessoa com experiência em design de código ▪ Fazer checks periódicos para falar de qualidade de código e arquitetura (com líderes do time) ▪ Fazer fishbowls/encontros com o time de dev e produto para falar sobre isso e analisar as oportunidades ▪ Começar o DDD com Strategic Modeling e não Tactical patterns
84. Comece a praticar DDD com Strategic Modeling Não começa com Tactical Pattern. Sério.
85. Strategic Modeling vs Tactical
86. Strategic Modeling te dá limites e uma definição clara do seu sistema
87. Strategic Modeling ▪ Linguagem ubíqua ▪ Definir domínio e subdomínio ▪ Definir bounded contexts ▪ Context maps
88. Definir bounded contexts É um componente tão importante quanto a linguagem ubíqua ao praticar DDD. É como o DDD lida com modelos ou subdomínios grandes: Separando eles por intenções do negócio.
89. Sistema e-commerce Domínio
90. Sistema e-commerce
91. Sales Context Inventory Context
92. exercício ▪ Faça uma lista de todos subdomínios que você se lembra dentro do seu dia a dia ▪ Faça uma lista de bounded contexts ▪ Use o template anterior pra entender como os bounded contexts se integram/relacionam ▪ Faça e refaça quantas vezes for necessário
93. afirmação Muitas pessoas e features para serem administradas. Os requisitos mudam e isso requer muito esforço do time em pensar como manter o código atual e ainda fazer as mudanças necessárias sem que outras coisas quebrem no sistema. Cenário #4
94. afirmação Muitas pessoas e features para serem administradas. Os requisitos mudam e isso requer muito esforço do time em pensar como manter o código atual e ainda fazer as mudanças necessárias sem que outras coisas quebrem no sistema. Cenário #4
95. afirmação Muitas pessoas e features para serem administradas. Os requisitos mudam e isso requer muito esforço do time em pensar como manter o código atual e ainda fazer as mudanças necessárias sem que outras coisas quebrem no sistema. Cenário #4 diagnóstico Chegou o momento esperado de investir em design de código e praticar DDD o quanto for possível. É hora de planejar mudanças no seu sistema.
96. afirmação Muitas pessoas e features para serem administradas. Os requisitos mudam e isso requer muito esforço do time em pensar como manter o código atual e ainda fazer as mudanças necessárias sem que outras coisas quebrem no sistema. Cenário #4 diagnóstico Chegou o momento esperado de investir em design de código e praticar DDD o quanto for possível. É hora de planejar mudanças no seu sistema.
97. O que você pode fazer ▪ Junte todo o esforço em Strategic Modeling para usar tactical patterns ▪ Planeja as mudanças e mão na massa
98. Perguntas durante o planejamento
99. Quais recursos de software já existem e podem ser reutilizados?
100. Quais recursos de software vão precisar ser criados do zero?
101. Quanto de esforço queremos colocar nesses recursos sendo criados do zero?
102. Tem alguma integração entre contextos que precisará ser feita do zero?
103. Strategic Modeling + Tactical Pattern
104. Tactical Patterns E também mais práticos que os utilizados no Strategic Modeling. Vale ressaltar que esses patterns são aplicados dentro de um bounded context São recursos mais próximos do código
105. Alguns patterns ▪ Value Objects ▪ Entities ▪ Domain Services ▪ Repositories ▪ Aggregates
106. Objetivo de cada pattern
107. Patterns de relacionamento entre bounded contexts ▪ Shared Kernel ▪ Customer/Supplier ▪ Conformist ▪ Partner ▪ Anti Corruption Layer
108. Pense bem antes de escolher
109. Pense bem antes de escolher
110. Conteúdos sobre DDD Implementando DDD, Vaughn Vernon Tactical Domain Driven Design Strategic Practices of DDD
111. Código é só uma maneira de trazer mais valor pro negócio
112. Código é só uma ferramenta que ajuda pessoas
113. muito obrigada! @carolkarklis