Own Your Domain Before It Owns You

It's bugs that make Software tumble, but it's blurred boundaries that make it collapse for good. In case of doubt, experts will simply slap the "Domain-Driven-Design" label around, but what does that even mean and how can we actually put something like that into practice?
In this talk we will take a look at what Modularity across your Domains actually boils down to, why it even is a necessity to stay sane and how to actually implement it into your Java systems. We'll take a look at how bounded contexts should be your best friends as a developer and why everything is an API. Expect fun anectdotes from mistakes we made in the past, a philosophical deep dive into organized coding and practical guidance for building systems that are not even that terrible to maintain.

Transcript

2. Do it RIGHT. What about us? 4 • ”Optimizing" my dev setup since 2019 • @ Posedio since 2025 • plays with both types of keyboards • spends 4 hours in a YAML to save 5 seconds of turning on a light bulb Leo Bowen Wang
3. Do it RIGHT. What about us? 5 • Code Therapist of 10+ years • Professional Software Roaster • @ Posedio since 2022 • Call me daddy (of almost 2) • Unpopular opinion: “animals are friends, not food” Philipp Seifert-Kehrer
4. Do it RIGHT. Roadmap 6 1. Why care about the domain? 2. What we are taught 3. Approaching that Domain Thing 4. Do it with Java 5. Back to the why
5. Do it RIGHT. 7 1. Why care about the domain?
6. Do it RIGHT. Why care about the domain? 8 To avoid…
7. Do it RIGHT. Why care about the domain? 9 Cannot get rid of complexity → have to tame it
8. Do it RIGHT. Legacy != Old… 10 You’re just out of touch with it
9. Do it RIGHT. Is this my job? 11 • A chef shouldn't have to understand tax logic or discount codes Blurred boundaries are the death of maintainability. • An accountant shouldn't need to know the temperature of the pizza oven
10. Do it RIGHT. Why care about the domain? 12 The Breaking Point
11. Do it RIGHT. 13 2. What we are taught
12. Do it RIGHT. What we are taught - Three-Tier Architecture 14 Presentation Layer Business Layer Data Access Layer
13. Do it RIGHT. What we are taught - Don't Repeat Yourself 15 “Duplicate code is bad”
14. Do it RIGHT. What we are taught - Database-First Design 16 Bottom-Up X Æ A-12
15. Do it RIGHT. What we are taught – Access Modifier 17 It’s treated as a way to "hide data” for devs.
16. Do it RIGHT. The “Anemic” Pizza 18 POJO that contains state but lacks behaviour
17. Do it RIGHT. The “Anemic” Pizza 19 One service must do EVERYTHING
18. Do it RIGHT. Horizontal Slicing 20 Customer Project Management Requirement Engineering Frontend Controller Service Database
19. Do it RIGHT. What we end up with (a lot of times) 21 Looks familiar?
20. Do it RIGHT. Is this my job? 22 • A chef shouldn't have to understand tax logic or discount codes Blurred boundaries are the death of maintainability. • An accountant shouldn't need to know the temperature of the pizza oven
21. Do it RIGHT. Why care about the domain? 23 The Breaking Point
22. Do it RIGHT. 24 3. Approaching that Domain Thing
23. Do it RIGHT. Vertical Domain Slices 25 Stop thinking in "Entities” Start thinking in Transactions – Processes > Data Horizontal separation of responsibilities is a lie Business rules matter Own your domain
24. Do it RIGHT. • A "Pizza" isn't a single global entity, its meaning changes depending on who is looking at it. One Object, Many Hats • Each context is a "protected zone." Logistics shouldn't know how the dough is kneaded, and the Kitchen shouldn't care about the delivery route. The API Wall Different Contexts 26 Same Name, Different Realities
25. Do it RIGHT. You’re not a designer 27 … in fact you do not have much to say at all
26. Do it RIGHT. DDD 2.0 28
27. Do it RIGHT. Put on that Requirements Engineering Hat 29
28. Do it RIGHT. Put on that Requirements Engineering Hat II 30
29. Do it RIGHT. In an ideal world… 31
30. Do it RIGHT. What about that fancy blue book? 32
31. Do it RIGHT. What about that fancy blue book? II 33
32. Do it RIGHT. What about that fancy blue book? III 34 Ubiquitous Language Putting things together that belong together Bounded Contexts
33. Do it RIGHT. Ubiquitous Language 35 Overrated?
34. Do it RIGHT. What about the language 36 Introducing…
35. Do it RIGHT. Putting things together that belong together 37 Seems easy at first, but…
36. Do it RIGHT. Putting things together that belong together II 38 All Services? All Data that is synced from the same outside source? All Data that has the same lifecycle? What they have in common?
37. Do it RIGHT. Bounded Contexts 39 Pizza can mean different things depending on the context
38. Do it RIGHT. 40 4.
39. Do it RIGHT. Business Processes First 41 Top-Down Look at holistic transactions Does not go well with RESTful
40. Do it RIGHT. Visibilities are your friend 42 Packages are not just folders! Don’t leave the door open if you don’t want strangers to eat and comment on your homecooked food! … even if not the most reliable
41. Do it RIGHT. Visibilities are your friend II 43
42. Do it RIGHT. The Model – API 4 your Data 44 DB Table != Model Entity != Model DTO != Model (but might be close) 1 Table != 1 Entity 1 Model != 1 Class Differentiating Technical & Domain Abstractions
43. Do it RIGHT. The Model – API 4 your Data II 45 Filtering & Funnelling
44. Do it RIGHT. The “DDD” Pizza 46 • Moving logic into the entity to make illegal states unrepresentable • Rules belong where they cannot be bypassed
45. Do it RIGHT. The “DDD” Pizza 47 • Reducing the service to a simple transaction wrapper
46. Do it RIGHT. The shared kernel trap 🪤 48 Dependency not represent data flow No compilation error on removing module
47. Do it RIGHT. The Conscious Dependency 49
48. Do it RIGHT. The Conscious Dependency II 50 Mindset Don’t let dependencies “just happen” Always observe and steer them Between packages, modules, projects
49. Do it RIGHT. The Orchestrated Workflow 51
50. Do it RIGHT. The God Module 52 Aka you did it wrong
51. Do it RIGHT. 53 5. Back to the why
52. Do it RIGHT. A Manager’s Dream? 54
53. Do it RIGHT. Final words 55 • Encapsulation • Everything is an API • Dependency-Aware Development > DAD (not dependency avoidant) Mindset Gonna have to deal with them Requirements Pizza != Pizza
54. Do it RIGHT. Big Thanks! 56 & ways to stalk us