Model

pioneers: lean settlers: agile town planners: 6-sigma src: Session_ Team Topologies origin: Simon Wardley? seems to overlap with Model_ 3X - software stages

Model: required vs actual communication ideal: required level of communication = actual level of communication often: mismatch between required level of communication actual level of communication solution A) increase actual communication solution B) decrease required communication ««< = Team Topologies todo: illustration (notebook p60): y axis: how much communication x axis: nothing / 2 different approaches src: Session_ Team Topologies origin: Matthew Butt

Notification “hey something happened” does not contain enough data eg. only orderId forces you to go to the source for more information Model_ Domain Event contains relevant data (src: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018)

Habit_ look for your heuristics and competing heuristics Heuristics competing against Favour Composition over Inheritance Heuristic: Use inheritance when template pattern fits Heuristic: Use inheritance when is-a Heuristic: Use inheritance when behaves-like-a Heuristic: Use inheritance when and only when there is inheritance in the domain Heuristics competing about reality Heuristic: Don’t model reality, evaluate for usefulness…driven by the domain Heuristic: immutable in reality => immutable in code invoice - ready, signed off, sent out, does not change anymore Heuristic: when your solution involves breaking&entering, find another solution Heuristics to help find competing heuristics...

Identify your personal heuristics Whenever you are faced with a design problem, and you have an idea of what you want the solution to be. Then your instinct should be "wait, why is this better?" "what heuristic did I apply to move from this design to that design?" gut feel -> name / label it (src: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018)

contain redundant information in Event Sourcing not fat when they only contain the delta of what changed How do you decide what attributes to put into a published event? see: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018 (src: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018)

1) What are the forces here? domain assumptions context technical forces constraints DDDers not just learn the rules from the business ... what are the forces here? how does this business assess risk? how much do they care about certain risks? the balance between making more money and taking more risk how do they look at customers? - employees that get fired if they do something wrong - millions of users with little control mapping assumptions...

Patterns are what you discover Principles are what you’re supposed to do Heuristic are strategies to progress in solving a problem, without guarantees Patterns are descriptive “sometimes mis-used as prescriptive, overusing, eg. when new in the field” goal: communicate about solutions not: use this everywhere, asap (prescriptive) Principles & Best Practices are prescriptive applied almost blindly best practice guarantee “if you always apply the best practice, you always get the best result”...

Views logical process development physical (aka deployment) +1 = scenarios (aka use cases) (src: Course_ ADSD - Intro to SOA)

Model: Clue Bucket Clue bucket = toolbox (@ruthmalan) insights patterns best practices design principles proposal: add Design Heuristics (src: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018)