Graph Ocean 又名：Nebula Java ORM。
由于 nebula-java-client 中 Session 是由 NebulaPool 所产生，且 com.vesoft.nebula.client.graph.net.NebulaPool#getSession 每次获取 Session 都需要传入用户名、密码等不变配置，所以想要加强 Session 则需要同步加强 NebulaPool 类
加强的连接池管理和 Session 管理有如下优点：
- 获取 Session 时不用每次指定用户名、密码和重连次数，交由加强类管理；
- 微服务时代，每个应用通常只对应了一个图空间（space），加强之后不必每次指定 space；
- 加强类区分了查询和更新操作，并且查询封装了自己的返回 POJO，为实体类的转换打下基础。
本套 ORM 框架是使用注解将实体映射到数据库元素的，有点仿 JPA 的意思。
注解包括：
- GraphVertex：顶点 Tag
- GraphEdge：边类型
- GraphProperty：图属性
其中包括主键策略（因为没有图空间实体映射，主键策略放在了顶点 TAG 的注解上），ID 是否作为属性、属性格式工厂等设置。
精炼之后的整体骨架设计图如下：
有了上面的注解定义，于是应该有注解解释器，将注解标注的实体映射成图空间中的元素，而元素也是一种抽象概念，它有两种形式：TAG 和 EDGE，这两种有很多共同的特性。
注解映射成抽象元素的过程，一般不常变，所以每次应用第一次解析成抽象实体之后，都应该缓存起来，所以有了缓存管理。
将实体解析映射成抽象图元素以及抽象图元素的实体是一个复杂的解析过程，并且 Tag 和 Edge 的解析略有区别，所以区别对待。
POJO 中的属性值和 Nebula 中的字段值不一定是一致的，所以需要向用户提供开放接口。
在基础 Mapper 中封装了写和查询的方法，但写和查的引擎又是分开的。
更新和查询都会运用缓存中的抽象元素实体，所以缓存中的元素统一由 GraphTypeManager 管理
查询中可能会有一些比较复杂的语句，比如条件过滤，case when 等，所以引入了 GraphExpression 和 GraphCondition 两种概念，而 GraphCondition 又继承了 GraphExpression。
结果返回封装类：QueryResult。
上面的设计完成之后，再辅助一些工具类和异常管理，整个 ORM 框架即呼之欲出。