Introduction to DDD by Paulo Phagula at GDG DevFest Maputo 2017

Presented at the GDG DevFest Maputo, this talks provides an easy to digest introduction to DDD.

Transcript

1. Domain-Driven Design Introdução
2. Yo! • @dareenzo everywhere • tea not coffee (last 24 hours) • vim not emacs • spaces not tabs (!Makefile)
3. Aviso Legal • Portinglês • Game of Thrones Spoiler Alert • Contains highly-contagious traces of controversial ancient wisdom • YMMV • I didn’t (won’t) violate any dark-secret pacts I have with my employers / customers / family & friends today
4. "Technique, is a trap. Style, is a prison. Kung fu is meant to liberate”
5. porquê importa? • "Software is eating the world” • "Many agile projects are now, steadily and iteratively, producing crap code” • Developers estão muito focados em tecnologia e base de dados (complexidade essencial vs técnica)
7. –Eric Evans - [DDD] “In order to create good software, you have to know what that software is about. You cannot create a banking software unless you have a good understanding of what banking is all about. One must understand the domain of banking.”
8. como ajuda? • tem um histórico de sucesso em projectos complexos • provê princípios e padrões para resolver problemas complexos • ajuda a focar no negócio e nas prioridades estratégicas do mesmo
9. O Que é DDD? • Domínio significa um esfera de conhecimento, influencia e actividade sobre um dada situação • é também um conjunto de conceitos que através da sua aplicação nos permitem resolver problemas • DDD significa, fazer o design (de um software) orientado pelo conhecimento sobre a situação (em que o software se insere)
10. –James Shore - The art of agile development: Ubiquitous Language “Its a conundrum. The people who are experts in the problem domain - the domain experts - are rarely qualified to write software. The people who are qualified to write software - the programmers - don’t always understand the problem domain”
11. –Eric Evans [DDD] “If programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be build that way, but the project will never arrive at a point where power new features unfold as corollaries to older features.”
12. Principios • Foco no core domain • Iterativamente explorar modelos numa colaboração criativa entre domain experts e software experts • Falar uma linguagem ubíqua (ubiquitous language) em um contexto delimitado (bounded context) explicito • Escrever código que expressa esses modelos explicitamente
13. Áreas
15. Modelo • Um modelo é um sistema de abstrações que descreve aspectos chave selecionados de um domínio, que pode ser usado para resolver problemas no tal domínio • Modelos evoluem a medida que nossa compressão sobre o problema evolui • Um modelo possui linguagem (jargão) e pode ter várias representações
17. Linguagem ubíqua em um contexto delimitado • O padrão mais fundamental do DDD • Linguagem ubíqua é um jargão partilhado, sobre um modelo, que é usada por uma equipa em um contexto delimitado
21. Percebendo com um Exemplo • O MaleYaPepa bank pediu-nos que desenvolvêssemos um app USSD para que os seus clientes possam transacionar sem precisar dirigir-se a um ATM ou balcão. • Transacções OIC são feitas com NIB e transações internas são feitas com o Número de conta. O montante máximo permitido por transação é de 10K a menos que o cliente seja Premium. Transferências OIC de montantes acima de 100K devem ser remetidas via MTR. Os clientes devem ser notificados de cada transacção via SMS
23. Abordagem 1: Modelo Monolitico • Integração com o “Sistema" do banco • Integração com N-operadoras para USSD e SMS • Laravel + MVC + Eloquent + MySQL • Autenticação
25. Problemas • Mistura de Complexidade técnica e complexidade essencial • Uso de tácticas sem estratégia resultando em falta de priorização • Foco em tecnologia e Ausência de colaboração com domain-experts
27. –Sun Tzu “Every battle is won before it is ever fought… Tactic without strategy is noise before defeat”
28. –Vaughn Vernon “Design Estratégico é como fazer o rascunho antes De Entrar nos detalhes da implementação. Destaca o que é estrategicamente importante para o seu Negócio, como dividir o trabalho por importância E como fazer integrações da melhor maneira.”
31. • OIC, NIB, No de Conta, Cliente Premium -> Core Domain • USSD -> Supporting • SMS -> Generic • Autenticação -> ???
34. Context Mapping
36. Partnership
37. Customer-Supplier
38. Shared Kernel
39. Conformist
40. Anti-Corruption Layer
41. Separate Ways
42. Big Ball of Mud (BBoM)
44. Mecanismos de Comunicação • Messaging (Domain Events*) • RPC • REST • Database • FileSystem
45. –Dan North “Learning is the constraint.”
46. Não sabes nada (sobre este domínio), João das Neves
47. Aprender sobre o domínio
48. Its developers understanding, not your knowledge that becomes de software - @ziobrando
51. Facilitação • A aprendizagem é fundamental, mas deve ser rápida e precisa. Para isso existem várias técnicas de facilitação: • DDD Whirlpool - Eric Evans - @ericevans0 • BDD - Dan North - @tastapod • Event Storming - Alberto Brandolini - @ziobrando • User Story Mapping - Jeff Patton - @jeffpaton • Domain StoryTelling - Stefan Hofer - @hofstef
53. Tactics - Expressando o Modelo em Software Entity Value Object Aggregates Repository Aggregates Factories Ports & Adapters (Hexagonal Architecture) Domain Events Modules
55. O que não é DDD • TDD; BDD nor FDD • XP; CQRS; EventSourcing; OO; FP; REST; Micro-services; Containers nor Domain Model. • Um design pattern • Diagram-Driven Design (Gregor Hohpe) • Degenerative Disc Decease • Uma tecnologia ou metodologia
56. Não é igual
57. Complexidade Essencial vs Técnica
58. –Leonardo da Vinci “Uma obra de arte nunca está terminada. Ela apenas é abandonada”