é 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
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
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
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
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
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.
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
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.
▪ 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
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
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).
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
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
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
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
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.
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.
jnchito
o0h
skrb
d0riven
akiomatic
chiroruxx
har1101
gawa
utgwkk
irof
suikabar
ming_ayami
techseoconnect
soudai
ryanjones
lara
cassininazir
jonoalderson
geshan
shpigford
addyosmani
aleyda
axbom
skipperchong
