A quest at mapping Domain-Driven Design Heuristics @ KanDDDinsky

“We all use heuristics (even if we haven’t articulated them to others) to discover, understand, explore, create, modify, or extend complex software systems. Billy Vaughn Koen, in Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving, defines a heuristic as, “anything that provides a plausible aid or direction in the solution of a problem but is in the final analysis unjustified, incapable of justification, and potentially fallible.”

-Rebecca Wirfs-Brock

You can look at heuristics as a rule of thumb, they don’t guarantee to be optimal, perfect, logical or rational. Instead, they are based on our past experiences, not scientifically proven to work, but worked for us in the past. The thing about designing software is that nothing is certain. Every time I hear someone say ‘it depends’ that is a trigger for me to find out their heuristic. With this in mind, and by talking with Rebecca I started a site called DDDHeuristics.com in where we can collaborate to document and discuss these heuristics. In this session, I want to extend my search to ‘gotta catch em all’ and see how together we can map our Domain-Driven Design Heuristics. After a short introduction about heuristics, we will start exploring, distilling and mapping our own heuristics stories. With these stories mapped out we can find and share individual heuristics. We document them in a certain flexible way, where we have a question, the heuristic and give some examples and context. At the end of the workshop, you should get a clear overview of what heuristics are, how it can help you design, and how you can map them out in order to drive and implement your design and software.

Transcript