模型
模型是 Trantor 体系的核心，业务域中最重要的资源即模型，视图和逻辑都与模型相关联。
同时，模型及模型间关系的定义既是对具体业务的设计和抽象，也是驱动由 Trantor 构建的中后台系统的约定。
业务模型（Business Model）
业务模型需要基于具体业务场景，对该场景下真正参与业务行为，和起到用于承载这些业务行为间数据交互和行为产物的一种数据结构的抽象，它是对业务实体的一种形式化描述。
业务模型具有持久化特性，目前Trantor内置的数据库管理系统是MySQL，一个业务模型对象对应于数据库中的一张模型元信息表和一张业务数据表。
- 模型元信息表：用于存储和描述业务模型元信息，比如：模型名称描述、类/属性字段定义、继承关系，业务实体关联关系、索引配置等等；
- 业务数据表：存储业务过程需要的真实数据，例如商品表存储商品ID、名称、描述、图片、分类、品牌等等。
例如，电商中的下单场景，一般会涉及到商品、用户、订单等具体的数据对象，皆可作为业务模型声明。
非持久化模型（Transient Model）
非持久化模型又叫瞬时模型。
与业务模型不同，顾名思义，非持久化模型不具备持久化特性，不会存储具体的业务数据，但是依然会保留一张模型元信息表。
非持久化模型一般用于数据间传输的场景，作为行为交互过程的信息载体，但这些信息对于业务来说不需要存储。
搜索模型（Search Model）
搜索模型主要是为了增强业务模型在大数据量模糊查询场景下的检索能力。
由于MySQL并不适合用于处理大数据量查询需求，所以我们引入了当下应用广泛并具有优秀性能表现的分布式搜索和分析引擎 Elasticsearch ，为了在机制层面上屏蔽掉对 ES 的操作处理，给开发人员提供更加易用的使用方式，因此引入了搜索模型的概念，作为Trantor的一种资源纳入到MetaStore的资源管理体系内。
搜索模型的数据来源一般是从一个或者多个业务模型中抽取字段组成的便于查询的新模型。因此在业务模型相应字段数据发生变更时，需要同步变更数据到搜索模型中。
配置模型（Setting Model）
在分布式系统中，必然会有配置中心和事件监听的功能需求，例如数据库连接信息修改，账号密码变更下发通知，黑白名单即时生效、服务限流阈值和降级开关，或者流量动态调整等等。
配置模型正是为了满足这种需求诞生的，通过创建配置模型和对应的监听器实现配置信息变更后的实时获取，和及时通知下游应用。
快照模型（Snapshot Model）
业务上有很多保存快照数据的需求，比如订单中的商品，会保存当时下单时的商品详情，价格，属性等等；最初的做法是业务方通过一个 Json 字段来保存，或者设计一些冗余字段来存储对应字段。
上述方法肯定可以一定程度上满足业务需求，但是需要额外的开发；而且会造成一些额外的数据存储成本，因此 Trantor 考虑统一提供一种模型快照机制；可以在模型层面声明快照模型，每当原模型发生变更（Create/Update/Delete）时，自动产生快照记录。同时可以在业务模型上可以声明快照链接，当尝试保存时，会获取最新的快照记录保存. 这样就可以关联当时的快照记录，并且可以根据快照进行搜索。
查询模型（Query Model）
查询模型是一种在现有机制下的衍生产物，只为查询行为服务。虽然查询模型不是 Trantor 中的模型（特指持久化模型和瞬时模型），但他也可以作为 Function 和 Extension 入参和出参。