I started to collect heuristics after Rebecca Wirfs-Brock workshop at DDD Europe 2020. And because I believe that the knowledge belongs to the community, I created this project. Also, most of the heuristics are not mine, and I capture it along the years.
It can help to design your software, your organisation and everything is between.
I use Rebecca's QHE (Question, Heuristic, Example) technique. You can start with any of the components, the important is to record the information.
For this project, I also added the event where the heuristic was capture, the date (not accurate) and the person that inspired me. I believe that it is essential to give the context about the heuristic.
You can help in several ways:
- Give feedback on GitHub or Twitter
- Spread the word
- Correct the data of the heuristic
- Add your heuristic, I would love to see what the community is doing
It is Creative Commons. Yeah, it belongs to us...
- 3C, communicate, communicate, communicate
- Accommodate the team
- Annotate ideas for later
- Be aware of the reliabilty trap
- Be intentional
- Beyond the meeting room
- Capture examples as you go
- Change tools to gain new perspectives
- Consider deployment when do modelling
- Decentralise the governance model
- Deeper understanding of the language, we understand the outside influences
- Do retrospectives often
- Do what you preach
- Don't allow the model from one bounded context to propagate
- Don't design for future unknowns
- Don't distribute objects
- Don't make things more complex than they are
- Financial reward good design
- Ghost other people
- Have orange stickies with you
- If you don't know, ask
- If you want to speed up, split up
- Leverage fine-grain investments
- Look for a platform that allows customisations
- Look for a tech stack that has a good pool of devs
- Look for coupling in unexpected places
- Make implicit, explicit
- Make things work for the team
- One command one event, is a smell
- Online meetins, strict rules, then loosen up a bit
- Pair to facilitate a modelling session
- Prefer price based utilisation not invariants
- Refactoring as you read
- Represent concepts in a X/Y axis
- Slower is faster
- Start with end in mind
- Take time to discuss concepts
- The cheapest software is the one that doesn't go to production
- The transformation should be linguistic, not technical
- Think about core-tasks rather than core domains
- Think about data ownership
- Use security to define boundaries
- When it gets too crowded in your head, write it down
- When software came to be, it changes itself
- You design it, you build it, you run it