The Graph Data Modeling book lists and motivates 35 requirements for a modern data modeling "solution". This is not ment to be another "manifesto", but it represents an effort to scope a framework, which does the job with higher quality and speed than legacy approaches. The list comes here:

General requirements

1: A three level data model architecture.
2: The business facing level must be built on the concept model paradigm (for visualization and effective learning).
3: The solution level data model is independent of data store platform and is derived from the concept level model.
4: The physical level data model is specific to data store platform but the content should be easily mapped back to the solution level data model by way of visualization of denormalization, collections and aggregates.

Business level requirements

5: The business level must support terminology and structure.
6: The business concept model should be easy to understand intuitively by business people, who know the business, but do not know the details of IT solutions.
7: The terminology should be that of the business.
8: The business concept model should be easy to produce and maintain.
9: There should be visualization tools available for concept modeling, and they should be easy to work with for business people.
10: Automated elicitation procedures may be employed (such as text mining and machine learning).
11: Business Objects.
12: Properties of business objects.
13: Atomic values (for illustration purposes).
14: Named, directed relationships with simple cardinalities.
15: Directed style for relationships between business objects.
16: Undirected style for relationships between a business object and its properties.
17: Generic data types (e.g. number, string, date, amount).
18: Definitions of the terminology used (word lists with explanations and examples).
19: Simple business rules written as text.
20: The Business Concept Models should be approved by the business people, including the sponsors.

Solution level requirements

21: The solution model is effectively derived from the business concept model. This means that some concepts become logical business objects, whereas other concepts become properties of those business objects.
22: The subset of the business concept model is gradually (iteratively) extended with design decisions.
23: It should be easy to establish the lineage from a design object to the business concept model.
24: The solution model must be visual and the structures being visualized should resemble the structure of the business concept model. (This actually follows from the derivation approach.)
25: Uniqueness constraints should be defined.
26: Since identity is closely related to uniqueness, support for that should also be present.
27: There should be support for identifiers, including surrogates.
28: There will also be technical and auditing data specified as well as data designed to handle time aspects, such as time series data.
29: Cardinalities will be defined on all relationships.
30: Business Objects (concepts, which may be referenced from other concepts, and which have properties).
31: Properties of business objects (properties are concepts, which share the identity of the business object that owns them).
32: Named, directed relationships with precise cardinalities.
33: Simple types (number, string, date, amount...).
34: Since directed graphs are behind all other data models as the inherent structure, as well as for the business semantics, the property graph data model is the chosen paradigm for representing solution data models.

Physical level requirement

35: It should be relatively easy to establish the lineage from the physical model to the solution data model and further on to the business concept model.
You may follow the sequence or explore the site as you wish:

You could also take a look at the book about Graph Data Modeling:
Stacks Image 72