3. Eficácia = valor correto para o cliente
custo total de propriedade
Custo Custo Custo total
desenvolvimento manutenção propriedade
Entender Modificar Testar Distribuir Manter
6. DDD
Domain-Driven Design não é
• Tecnologia
• Metodologia
• Arquitetura
• Repositorio
• Bala de prata
• Receita de bolo
7. DDD
Domain-Driven Design é, na verdade:
• Modelagem de negócio
• Coleção de princípios e práticas
• Focar os esforços de design onde
ele é mais importante
8. DDD
Foco no domínio
Design do domínio é baseado em um modelo
23. TDD
Test-Driven Development
• Desenvolvimento guiado por testes
• Mas não é sobre testes
• É sobre design
• É sobre código funcionando
• É sobre código posto a prova
25. TDD
Exemplo
• Como Banqueiro quero negar débitos na
conta corrente de determinado cliente
caso ele não tenha saldo suficiente para
pagá-lo, assim, eu não perderei dinheiro.
Agenda da palestra Relembrar o manifesto ágil e dizer que as práticas *DD podem ser perfeitamente encaixadas no manifesto: Individuos e interações entre eles: DDD e suas colaborações entre o time de negócios e o time de desenvolvimento Software em funcionamento: TDD garante feedback rápido do seu código, garantindo que ele está funcionando Colaboração com o cliente: BDD faz com que o desejo do cliente vire código “ na frente dos seus olhos ” Responder a mudanças: *DD faz com que as mudanças não sejam vistas como vilãs
Mostrar que estas práticas podem se traduzir uma maior eficácia no seu projeto. Estas práticas, em primeiro momento, podem aumentar o custo de desenvolvimento, porém irá certamente diminuir o custo de manutenção, uma vez que há a certeza do impacto que determinada alteração terá no código como um todo.
Um projeto de software é uma troca entre o Negócio (dominio), a tecnologia e a equipe. O domínio deve vir do aprendizado trocado entre a equipe e o negócio, respeitando e por vezes superando os limites que a técnologia impõe.
Já que um software reflete uma realidade de negócio, o Domain-Driven Design vem para tratar toda esta complexidade no “ coração ” do software.
As confusões que as pessoas fazem sobre o DDD. Falar sobre cada uma delas
Uma maneira de modelar o negócio Uma coleção de principios e práticas Uma maneira de focar os esforços de design onde ele é mais importante
Falar sobre a importancia da linguagem única e a visão compartilhada entre a equipe de negócios e a equipe de desenvolvimento
Falar sobre o que é um modelo, sua representação da realidade, de um conceito, uma ideia. Modelos podem ter mais detalhes ou menos...
Provocar a platéia sobre como representar um modelo de negócio
Falar sobre método científico, etc.
Falar sobre a base do tdd, o ciclo básico e etc
Imagina se aquele problema do double vai para produção...
Falar sobre qualidade, qualidade externa e qualidade interna. Sobre o teste de unidade, teste de integração e testes ponta a ponta.