LIST
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”...
no solution offered no context offered only tells “there might be a problem” (src: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018)
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)
something that has happened in the past that is relevant to the business (src’s src: from summary book Eric Evans (not the blue book) ) (src: Video_ Design Heuristics - Mathias Verraes - KanDDDinsky 2018)
(src: https://www.youtube.com/watch?v=9ZgSz6xAfL8) Model_ Clue Bucket (aka toolbox) Model_ Patterns vs Principles vs Heuristics Model_ distill your heuristics Model_ competing heuristics Heuristic: things that change together should stay together named: Single Responsibility Model_ Method for deliberate design choices Exercise Model_ Domain Event Exercise: Which attributes should be in this domain event? who placed it when was it placed Heuristic: when did something happen, is that relevant? Heuristic: what are all the timestamps that matter when it happened when we learned about it when we recorded it pre-dated who cares about this?...