Tweet
Tweet

Slide 1

Slide 1 text

Your Tech-Stack is awesome but so is your domain MICHAEL PLÖD FELLOW

Slide 2

Slide 2 text

Michael Plöd Fellow at INNOQ Mastodon (or Twitter): @[email protected] 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

Slide 3

Slide 3 text

Get my DDD book cheaper Book Voucher: 7.99 instead of (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck

Slide 4

Slide 4 text

Why did you become a software engineer?

Slide 5

Slide 5 text

Tech is awesome

Slide 6

Slide 6 text

your domain and some business stuff Let me motivate you for

Slide 7

Slide 7 text

Don’t be afraid: I don’t want to turn you into a business suit

Slide 8

Slide 8 text

Instead I think that business and domain knowledge will make you a more valuable developer Photo by Jon Tyson on Unsplash

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

„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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

We can drive this even further

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Let me tell you a story Michael as a young developer for a mortgage loan scoring engine

Slide 18

Slide 18 text

Michael Requirements 
 Engineers Risk 
 Managers

Slide 19

Slide 19 text

I had a great and thorough speci f ication

Slide 20

Slide 20 text

The starting point

Slide 21

Slide 21 text

Let’s look at the business rules

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

The rules in the bigger picture

Slide 24

Slide 24 text

The speci f ication implied the following structure

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

So I built my scoring engine according to that structure which I assumed in my head which roughly looked like this

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

The acceptance test and a change in communication

Slide 29

Slide 29 text

Michael Requirements 
 Engineers Risk 
 Managers

Slide 30

Slide 30 text

I developed a bad gut feeling but go-live was f ine, just two minor bugs. 
 
 But then came a new requirement…

Slide 31

Slide 31 text

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?

Slide 32

Slide 32 text

Michael: „this affects nearly everything“

Slide 33

Slide 33 text

Risk Management: „no, it’s only in one part“ ?

Slide 34

Slide 34 text

The risk managers started to think that I do my surname justice 
 (just replace the P in Plöd by a B)

Slide 35

Slide 35 text

They had a different mental model

Slide 36

Slide 36 text

Everyone was right, from their perspective

Slide 37

Slide 37 text

I refactored my code to their mental model and the new requirement was suddenly very easy to implement

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

„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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

Design Level EventStorming

Slide 44

Slide 44 text

Starting point

Slide 45

Slide 45 text

Chaotic Exploration on business rules

Slide 46

Slide 46 text

You can already start to write tests!

Slide 47

Slide 47 text

Which grouping of the rules is the right one?

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

We already talked about modularization on a lower level…

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

Modularization on a higher level

Slide 52

Slide 52 text

Text... Shape... Color... Size... There are many choices to group domain concepts Output quantity

Slide 53

Slide 53 text

George Box All models are wrong, some are useful

Slide 54

Slide 54 text

Who can give me a DETAILED description of the business model of your application including: 
 
 Customer Segments 
 Channels 
 Value Proposition 
 Cost Structure 
 Revenue Streams

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

„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.”

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

Who agrees with the following sentence? There are modularization options that work for or against a value proposition

Slide 59

Slide 59 text

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?

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Book hints

Slide 63

Slide 63 text

Check out DDD-CREW on GitHub https://github.com/ddd-crew

Slide 64

Slide 64 text

https://github.com/ddd-crew/ddd-starter-modelling-process

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

How the business names things TV Window Chair Trolley Painting Desk What we see in code TransparencyFactory RollableStuffContainer EntertainmentProviderSingleton DecoratorImpl RestProvider WorkEnablementDevice

Slide 70

Slide 70 text

EMPATHY

Slide 71

Slide 71 text

Food for thought

Slide 72

Slide 72 text

https:/ /architectelevator.com/

Slide 73

Slide 73 text

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“

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

Product Thinking 101 by Naren Katakam https://uxplanet.org/product-thinking-101-1d71a0784f60 Technology Product Users Business

Slide 77

Slide 77 text

„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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

What does this management term digitalization 
 mean?

Slide 80

Slide 80 text

What is the 
 purpose of digitalization 
 from a business perspective

Slide 81

Slide 81 text

Purposes of digitalization Digitalization Improve an existing business model with tech Create a whole new business (model) enabled by tech

Slide 82

Slide 82 text

The words business & tech appeared together in both purposes Did you realize?

Slide 83

Slide 83 text

„Let’s just introduce DevOps!“

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

Source: https://amplitude.com/blog/journey-to-product-teams-infographic

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

I am convinced that business and domain knowledge will make you a more valuable developer Photo by Jon Tyson on Unsplash

Slide 88

Slide 88 text

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: [email protected] Socials: @[email protected] 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