Архитектура приложения на основе Neo4j — придерживаться ванильного API, используя простые узлы и отношения, или использовать Spring/GORM?

Я надеюсь услышать от любого из вас, кто спроектировал и реализовал приложение Neo4j приличного размера (10 миллионов узлов/отношений), и что ваши рекомендации особенно касаются моделирования и различных API (vanilla java/groovy Neo4j против Spring-Data-Neo4j против Grails GORM/Neo4j).

Мне интересно, действительно ли окупается добавление дополнительного слоя OGM (object-graph-mapping) и связанных с ним абстракций?

Кто-нибудь знает, что лучше придерживаться «простого» графового моделирования с узлами+свойствами, отношениями+свойствами, обходами и (например) Cypher для моделирования и хранения своих данных?

Меня беспокоит то, что «принудительное применение» конкретной абстракции OGM к графовой базе данных повлияет на будущую гибкость в адаптации/изменении модели предметной области и/или гибкость в запросе данных.

Мы магазин Grails, и я экспериментировал с GORM/Neo4J, а также с spring-data-neo4j.

Основная цель набора данных будет заключаться в моделировании и запросе отношений между v. большим количеством людей, их псевдонимов, их сообщников и всех видов преступной деятельности и истории. Будет более 50 основных доменных классов.Модель должна быть гибкой (которая должна будет быстро развиваться на ранних этапах проекта), а также скоростью и гибкостью запросов.

Должен признаться, я изо всех сил пытаюсь найти вескую причину для использования уровня OGM, когда я могу использовать (например) POJO или POGO, немного магии Groovy и какой-нибудь простой объект предметной области, созданный вручную <-> node/ код сопоставления отношений. Насколько я могу судить, я думаю, что был бы счастлив просто иметь дело с узлами, обходами и шифрованием (он же KISS). Но я был бы очень рад услышать чужой опыт и рекомендации.

Спасибо за ваше время и мысли,

TP