Your tech-stack is awesome but so is your domain

Of course we all love our favorite technologies and of couse it is important to understand your tech stack as a developer. Certainly you become a great developer or architect by understanding modern patterns and architectures.

But isn’t it a bit boring to just churn out code just for codes sake?

In this talk I want to motivate you to leave your comfort zone and to take a step back. This talk aims at motivating you as a developer or an architect to dig deep into the domain of your business and your product. I firmly believe that this will make you a great and especially a more valuable developer. If we understand the business we can make better design choices as developers / architects. We can highlight misalignments in our organization. We will be able to come up with better tests.

This talk will not just be limited to the motivating side of this topic. I will also give you tons of hints and tips how you can get started in this journey, who your allies may be and how to tackle this difficult task. This talk will also come with many examples of success and failure from the real world. I guess we will laugh a lot during this session but sometimes we’ll also shake our heads in utter disbelieve in those 50 minutes.

Transcript

1. Your Tech-Stack is awesome but so is your domain MICHAEL PLÖD FELLOW
2. Michael Plöd Fellow at INNOQ Mastodon (or Twitter): @bitboss@mastodon.social LinkedIn: https://www.linkedin.com/in/michael-ploed/ Current consulting topics: • Domain-Driven Design • Team Topologies • Transformation from IT Delivery to digital product orgs Regular speaker at (inter-)national conferences and author of a book + various articles
3. Get my DDD book cheaper Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
4. Why did you become a software engineer?
5. Tech is awesome
6. your domain and some business stuff Let me motivate you for
7. Don’t be afraid: I don’t want to turn you into a business suit
8. Instead I think that business and domain knowledge will make you a more valuable developer Photo by Jon Tyson on Unsplash
9. You write better code which is more maintainable You will make better modularization decisions You will communicate better and therefore be heard more You can make a signi f icant impact on the product design Your value will increase VALUE
10. You write better code which is more maintainable You will make better modularization decisions You will communicate better and therefore be heard more You can make a signi f Let’s approach this bottom-up VALUE
11. 11 Innovation Cycles Teams Market Look for signals from Great User 
 Experience Expects Software Is enabled by Is developed by Source: https://www.ntcoding.com
12. „the key to incremental architecture is to build on a framework that can accommodate change... that framework is the domain.... By modeling the domain, you can more easily handle changes to the domain“ Allen Holub https:/ /holub.com
13. 13 Innovation Cycles Teams Market Look for signals from Great User 
 Experience Expects Software Architecture Is enabled by Is developed by Business 
 Domain Should be 
 a model of Source: https://www.ntcoding.com
14. We can drive this even further
15. 15 “A loosely coupled software architecture and org structure to match” is a key predictor of: •Continuous Delivery Performance •Ability to scale organization and increase performance linearly
16. 16 Innovation Cycles Teams Market Look for signals from Great User 
 Experience Expects Software Is enabled by Is developed by Business 
 Domain Should be 
 a model of Should be 
 aligned with Source: https://www.ntcoding.com
17. Let me tell you a story Michael as a young developer for a mortgage loan scoring engine
18. Michael Requirements 
 Engineers Risk 
 Managers
19. I had a great and thorough speci f ication
20. The starting point
21. Let’s look at the business rules
23. The rules in the bigger picture
24. The speci f ication implied the following structure
26. So I built my scoring engine according to that structure which I assumed in my head which roughly looked like this
28. The acceptance test and a change in communication
29. Michael Requirements 
 Engineers Risk 
 Managers
30. I developed a bad gut feeling but go-live was f ine, just two minor bugs. 
 
 But then came a new requirement…
31. We want to see if a red scoring can become green with more own funds 
 
 if yes: how much more money do the applicants need?
32. Michael: „this affects nearly everything“
33. Risk Management: „no, it’s only in one part“ ?
34. The risk managers started to think that I do my surname justice 
 (just replace the P in Plöd by a B)
35. They had a different mental model
36. Everyone was right, from their perspective
37. I refactored my code to their mental model and the new requirement was suddenly very easy to implement
39. Key 
 Learnings It is essential that you understand the mental model which is in the heads of the business folks. Implement the structures in your domain logic code according to this shared understanding. Their requirements and assumptions stem from this mental model. Try to reduce the amount of implicit assumptions in your head as much as possible.
40. „It is not the domain experts knowledge that goes into production, it is the assumption of the developers that goes into production” 40 Alberto Brandolini Inventor of EventStorming
41. Use collaborative modeling methods Image for example mapping taken from: https://openpracticelibrary.com/practice/example-mapping/ 
 Image for user story mapping taken from: https://www.hanssamios.com/dokuwiki/how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list
43. Design Level EventStorming
44. Starting point
45. Chaotic Exploration on business rules
46. You can already start to write tests!
47. Which grouping of the rules is the right one?
48. You write better code which is more maintainable You will make better modularization decisions You will communicate better and therefore be heard more You can make a signi f Let’s approach this bottom-up VALUE
49. We already talked about modularization on a lower level…
51. Modularization on a higher level
52. Text... Shape... Color... Size... There are many choices to group domain concepts Output quantity
53. George Box All models are wrong, some are useful
54. Who can give me a DETAILED description of the business model of your application including: 
 
 Customer Segments 
 Channels 
 Value Proposition 
 Cost Structure 
 Revenue Streams
56. „When companies do not understand their customers’ or users’ problems well, they cannot possibly de f ine value for them. Instead of doing the work to learn this information about customers, they create a proxy that is easy to measure. ‚Value‘ becomes the quantity of features that are delivered, and, as a result, the number of features shipped becomes the primary metric of success.”
58. Who agrees with the following sentence? There are modularization options that work for or against a value proposition
59. How can we come up with proper boundaries for modules (be it in monoliths or microservices) when we don’t know or understand the value proposition?
60. Ask these questions •What value do we deliver to the customer? •Which one of our customer's problems are we helping to solve? •Which job are we helping the customer get done? •Which customer needs are we satisfying? •What bundles of products and services are we offering to each Customer Segment? Source: https://www.strategyzer.com/business-model-canvas/value-propositions
61. Types of value propositions •Newness •Performance •Customization •„Getting the job done“ •Design •Usability Source: https://www.strategyzer.com/business-model-canvas/value-propositions •Brand / Status •Price •Cost Reduction •Risk Reduction •Accessibility •Convenience
62. Book hints
63. Check out DDD-CREW on GitHub https://github.com/ddd-crew
64. https://github.com/ddd-crew/ddd-starter-modelling-process
65. 65 Bounded Context Design Canvas The canvas guides you through the process of designing a bounded context by requiring you to consider and make choices about the key elements of its design, from naming to responsibilities, to its public interface and dependencies. Source: https://github.com/ddd-crew/bounded-context-canvas
67. You write better code which is more maintainable You will make better modularization decisions You will communicate better and therefore be heard more You can make a signi f Let’s approach this bottom-up VALUE
69. How the business names things TV Window Chair Trolley Painting Desk What we see in code TransparencyFactory RollableStuffContainer EntertainmentProviderSingleton DecoratorImpl RestProvider WorkEnablementDevice
70. EMPATHY
71. Food for thought
72. https:/ /architectelevator.com/
73. Modern architects align organization and technology, reduce friction, and chart transformation journeys. In addition to working with UML and architecture styles, such architects ride the Architect Elevator from the penthouse, where the business strategy is set, to the engine room, where the enabling technologies are implemented. They shun popular buzzwords in favor of a clear strategy de f ined by conscious decision making. Gregor Hohpe Author of „The Software Architect Elevator“
74. You write better code which is more maintainable You will make better modularization decisions You will communicate better and therefore be heard more You can make a signi f icant impact on the product design Let’s approach this bottom-up VALUE
75. Shift from Projects to Products Tech-enabled Organizations •Tech is core strategic asset in product and not a cost center •No feature factories •Strong aim to insourcing of development of functionality which is core to the business
76. Product Thinking 101 by Naren Katakam https://uxplanet.org/product-thinking-101-1d71a0784f60 Technology Product Users Business
77. „Product thinking is the journey from the problem space of the users to the solution space of the business. The goal of this journey is to reduce the gap between users and the business.” Naren Katakam
78. Source: https://medium.com/agileinsider/what-we-learned-from-our-survey-of-550-product-managers-and-leaders-79340126ccab "If you're just using your engineers to code, you're only getting about half their value.“ Marty Cagan
79. What does this management term digitalization 
 mean?
80. What is the 
 purpose of digitalization 
 from a business perspective
81. Purposes of digitalization Digitalization Improve an existing business model with tech Create a whole new business (model) enabled by tech
82. The words business & tech appeared together in both purposes Did you realize?
83. „Let’s just introduce DevOps!“
84. You build it, you run it Business 
 Domain 
 Experts Developers 
 Architects Operations 
 DDD Dev 
 Ops You design it, you build it and you run it
85. Source: https://amplitude.com/blog/journey-to-product-teams-infographic
86. Source: https://amplitude.com/blog/journey-to-product-teams-infographic Moving the responsibilities 
 to the left requires developers 
 to understand the business 
 as well as the business to 
 understand tech
87. I am convinced that business and domain knowledge will make you a more valuable developer Photo by Jon Tyson on Unsplash
88. Krischerstr. 100 40789 Monheim +49 2173 3366-0 Ohlauer Str. 43 
 10999 Berlin 
 Ludwigstr. 180E 
 63067 Offenbach 
 Kreuzstr. 16 
 80331 München 
 Hermannstrasse 13 
 20095 Hamburg 
 Erftstr. 15-17 50672 Köln 
 Königstorgraben 11 90402 Nürnberg innoQ Deutschland GmbH www.innoq.com Thank you! Michael Plöd E-Mail: michael.ploed@innoq.com Socials: @bitboss@mastodon.social LinkedIn: https://www.linkedin.com/in/michael-ploed/ Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck