JCypher provides quite a couple of powerful features, especially concerning the handling of complex business domains. With these functional features and with non-functional features like transactions and concurrency support in place, it seems to make sense to extend JCypher's design, enabling JCypher to be run as a service.
By providing a RESTful interface, it shall be possible to deploy and use JCypher in a distributed, possibly heterogeneous environment.

A first step in that direction was done by implementing a 'Generic- (Dynamic-) Domain Model' (please see the previous post), which was introduced with release 3.0.0. The next step will be to implement a 'JSON-Facade' which can be invoked by a service-capsule, in order to provide a RESTful service interface to JCypher.

After the 'JSON-Facade' is in place, I plan to introduce a new project 'JCypher-Server', which will provide a server-side implementation of JCypher together with a browser interface, allowing to explore and work with 'domain graphs' based on JCypher features.

The domain model, i.e. the model of a domain graph (graph of Java objects) which is stored to / retrieved from a Neo4j graph database by means of JCypher 'Domain Mapping' or JCypher 'Domain Queries' respectively, is specified by those object's classes.

If you don't have access to these Java classes, a generic- (or maybe better a dynamic-) domain model comes in handy.
Here are some scenarios, which would highly profit from such a dynamic domain model:

• Tools for accessing domain graphs usually want to explore a domain graph or a domain model in a reflective kind of way. They want to be able to explore without having access to the domain model's classes.

• If you have access to a graph database with a stored domain graph, but you don't have access to the domain model classes, you still want to be able to work with the domain graph or the domain model respectively.

• If you want to open JCypher for access from other languages and / or for remote access e.g. via a REST-API.

(Was started with JCypher release 2.1.0 and extended step by step in the following releases).

At a higher level of abstraction, JCypher provides mapping of arbitrarily complex business domains to property graphs (Neo4J). Firstly, a default (generic) mapping is provided, which allows domain objects ('graphs' of pojos (plain old java objects)) to be stored to a graph database in a straight forward way. No additional configuration except for database access is needed. Simply construct your domain objects, instantiate a DomainAccess and call store(domainObjects) --> domainObjects is a list containing the objects you want to persist. The 'graph' of domain objects is mapped to and stored in the graph database.

Additionally, configuration of how to map domain objects to elements (nodes, relations) of a graph database, by means of a 'Native Java DSL', is (will be) provided. That is especially useful, if you want to map a graph to a domain which did not originally create the graph.

While a major advantage of the previously mentioned approach is the ability to easily persist and retrieve domain objects without the need to design and configure complex database schemas (as e.g. with relational databases), the true power comes from the fact that the 'graph' of domain objects is backed by a graph database (Neo4J). It allows to execute powerful queries on your business domain performing complex navigations of the object graph, because the queries are actually performed against the graph database.

As a simple example think of an instance of a class Person which contains a list addresses, holding objects of type Address. To query a person for its addresses is straight forward. But given you have an Address and you want to know all Persons who live at this Address, a traditional approach is of high complexity and mostly of poor performance. You would have to iterate over all Persons and test each one if it is related to the specific Address in order to collect those Persons.

Now when your business domain is backed by a graph database, the link between Person and Address is explicitly stored as a relationship and can easily be traversed in both directions. No need for joins (which often bear performance problems) as with relational databases. The more traversals you want to do in your query, the more advantage you gain when having your domain backed by a graph database. JCypher provides (will provide) a powerful 'Domain Query Language', which strongly inherits from the graph query language 'CYPHER' or JCypher's 'Query-DSL' respectivley. But in contrast it allows to formulate queries on the domain objects or their types respectively (instead of formulating queries on nodes and relations of a graph).

• Provide access to graph databases at a 'higher level of abstraction'. The idea is to map complex business domains in form of Java object graphs to graph databases.
  *** Firstly by providing a default generic mapping, which allows to store and retrieve object graphs without the need of any additional configuration.
  *** Secondly by providing a means to configure how to map a Java object graph to nodes and relations of a property graph by means of a fluent Java API (i.e. an additional 'Native Java DSL' actually).
  What is the advantage of the secondly mentioned approach?
  While common mapping mechanisms (e.g. Spring Data Neo4J) utilize annotations to define the mapping of objects, attributes, and relationships, the targeted approach uses a 'Native Java DSL' to specify the mapping. On the one hand this allows for specifying the mapping in an intuitive and IDE-tool supported way (just like the JCypher-Query-DSL). On the other hand it is completely non-invasive for the domain objects (not even annotations invading the domain objects). The plan is to develop a specific 'Native Java DSL' which utilizes the 'JCypher-Query-DSL' in order to define the mapping(s) in form of 'mapping expressions'. These 'mapping expressions' will be contained in 'configuration classes' which are separate from the business model classes. This allows to map the same graph to different models as well as to map the same model to different graphs (all done completely non-invasive for the model classes).

• Encapsulate complex graph algorithms. The idea is to provide simple interfaces to hide the complexity of advanced graph algorithms.

• Multi-Domain-Approach. The idea is to reuse 'Entities' across multiple business domains. This requires new design approaches, as well as concepts about how JCypher could support it.

• Using graphs to express constraints on other graphs. The idea is to design a 'meta model' which itself is stored as a property graph, and which expresses constraints (business rules) on other graphs.

After some time working with Neo4j, I am convinced that graph databases are not only the best solution for storing and of course for retrieving highly connected data, but also for storing and querying many of today's application's data.

I would even add a plus for the schema free approach. Usually, in solutions with relational databases as backend, constraints and business rules are split between schema definitions on the database and constraints implemented in the application code. I would prefer having all those constraints and rules in a single place.

My feeling is, that graph databases have the potential to substantially change the way how we architect, design, and implement our applications in the future (maybe also how we model them). I think e.g. about relations or relationships as first class citizens in our design of application models.

Let's construct a simple example about Person(s) and Address(es): In one application domain we could be interested in relationships between Person(s) and Address(es) (e.g. a sales application (relationship: shipTo)). In another application domain we could be interested in relationships between different Persons (e.g. a social media application (relationship: friends)). In common approaches that we apply today, reusing Person across different domains would be very difficult (if not impossible). Why?: For domain 1 (sales application) we would design a method getShippingAddress() in class Person, whereas for domain 2 (social media application) we would design a method getFriends() in class Person.

In that way we end up 'enriching' class Person with a lot of navigation methods, of which we are only interested in a small number in the context of a single domain.
Alternatively, viewing relationships as first class citizens of a domain (relationships actually structure a domain), we could end up with domain specific relationship classes such as SalesApp and SocialApp. These classes then would implement domain specific navigation methods: e.g. SalesApp.getShippingAddress(Person aPerson); SocialApp.getFriends(Person aPerson), thus allowing us to easily reuse class (or entity) Person across different domains (without polluting it with navigation methods of many different domains). This idea is strongly impacted by chapter 'Cross-Domain Models' of the book 'Graph Databases'. This shall be seen as just one example of how graph databases might influence (change) the way we design our applications.