Why DDD Matters Today

This was my keynote at KanDDDinsky 2017.

It's an interesting entry point behind the dynamics of Domain-Driven Design, during the rise of Microservices.

Transcript

1. Why DDD Matters Today @ziobrando
2. What is software development?
3. “Writing software is like building a house” Idea N° 1
5. #protip: they’re not *really* building a house
7. “We are translating requirements into working software” Idea N° 2
8. The benevolent wisdom of the domain expert Our eternal Gratitude
9. The shape of the organization
10. Just add a translator here…
11. The knowledge distribution
12. “It's a basic truth of the human condition that everybody lies. The only variable is about what.” Dr. Gregory House
14. Enterprise software development is discovery, challenge, and investigation
15. “Software development is a learning process Working code is a side effect”
16. Not all software development is the same “Core domain”
17. https://www.spreadshirt.de/selbst- gestalten? product=169608967&view=1#? af fi liateId=1246955&orgn=CYO&net w=LI
18. Delivery without understanding Pretty dumb idea Dominant pattern in enterprise software development
19. In the Core Domain, LEARNING is the key asset
20. Strategies for non-core Traditional On-Time / On-Budget Pseudo-Agile thing Follow the backlog Avoid Taking unnecessary risks No time for “gold plating”
21. Standard Approaches Won’t deliver in the CORE
23. Strategies for CORE Creative collaboration with domain experts Experiments Continuous refinement of knowledge AND implementation
24. There is no such thing as “Gold Plating” in the Core Domain
25. It’s “Gold Making” in the core
26. DDD is for domains that can’t be modelled right in one shot
27. 1) Too complex to be understood without experimenting
28. 2) Continuously Evolving
29. “Chasing the right model” AKA “Creative collaboration”
30. The business problem Our understanding Our implementation
31. If you can keep the three close…
32. The business problem
33. Easy!
34. 1) Understand the problem
35. What happens when you google “software developer” for images?
36. clueless dude in the middle Slacking off gears? Watching porn My man! xactly!!
37. Software development is a learning process
38. But we’re always doing “second hand” learning
39. 2) Keep the implementation as close as possible to our understanding #protip this is what Ubiquitous Language is all about
40. …of course we do!
41. Nobody writes bad software intentionally … or so we think!
42. We are just trying to do a good job!
43. The Cracks in the Monolith Making sense of a huge mess
44. “Every piece of knowledge must have a single, unambiguous, authoritative representation, within a system” Andy Hunt & Dave Thomas The DRY principle
45. “Every piece of knowledge must have a single, unambiguous, authoritative representation, within a system” Andy Hunt & Dave Thomas The DRY principle
46. Modelling Data-First Focus on nouns Expand the scope in order to accomodate new concepts … … Leave the company cursing the Legacy
47. Nouns won’t help Everybody agrees what an order is? Of course we do! An order is an order! And has a customer too! Agreed!
48. Perfect recipe: Talk with many people Model Data-First (everybody agrees on nouns) Add some “Dogmatic DRY principle” Repeat
49. The Big Ball of Mud I swear it was a monolith last time I checked!!!
50. A single model won’t solve an enterprise problem, We’ll need more!
51. Conceptual boundaries
52. Microservices Is Envy a driver for architectural choices?
53. … only to discover that they’re tangled with dependencies!! I spend most of my time rescuing teams that went micro services over a monolith…
54. https://www.dropbox.com/s/zb4imheanczmkc6/ Screenshot%202017-10-20%2000.20.11.png?dl=0
55. How do I untangle this mess?
56. Conceptual boundaries?
57. Bounded Context Is a LANGUAGE boundary. Defines a consistent MODEL around a specific PURPOSE #PROTIP: “Managing” is not a purpose
58. MicroService A DEPLOYMENT boundary: MICRO* means ‘as small as possible’ You are not necessarily Netflix
59. … so…?
60. … “so a Microservice is a bounded Context”
61. You’ve just collapsed two fuzzy concepts into one!!!
62. … Still I have no Idea what a Bounded Context is I have no Idea what a micro service is, but I am pretty sure it’s a bounded Context But I am using Docker!
63. … just being exilicit More microservices within a bounded context Just don’t call it “micro*” anymore.
64. You’re not Netflix!
65. But One thing is clear…
66. This works just better!
67. Domain Events Provide the best abstraction for modelling enterprise software
68. Safety You just won’t learn under pressure
69. Thin red line • Start a project with a data first approach • Add misunderstood DRY PRINCIPLE • Lack of control requires protection & specialisation • few people become key, others retire or get minionized Business grows on top of old code • SAFETY is gone. Without it, no experiments are possible. • More responsibilities: less time to change it, harder to make the call • Hard to recruit seniors to finish the job
70. Thin red line • Postpone evolutions of critical software • prevent the organisation from getting new feedback • -> how long are your iterations? • Suddenly realise that the organisation is dumbed down and blames IT for everything
71. They’re the same problem
72. Takeaways
73. High-Value enterprise software needs a special approach
74. Why DDD Matters now @ziobrando
75. Or maybe…
76. …because, after all these years…
77. We were just RIGHT!!!
78. Questions? Thank you!