Designing for query-ability

As with any database management system, but perhaps even more so for a graph database management system such as Neo4j, your queries will drive your model. What we mean with this is that, exactly like it was with any type of database that you may have used in the past or would still be using today, you will need to make specific design decisions based on specific trade-offs. Therefore, it follows that there is no one perfect way to model in a graph database such as Neo4j. It will all depend on the questions that you want to ask of the data and this will drive your design and model.

Therefore, my number one rule, and undoubtedly the most important best practice for graph database modeling, is to start with your user stories. What does the user of the system that you are designing want to know from the data? An example of such a story could be something like this:

This excerpt tells a little bit about the entities that I need to include in the model and the connections that should exist between these entities. Different domain descriptions would probably add similar or different entities and similar or different connections and will then gradually complete your model.