2. Domain Model
The term domain model comes from the realm of data modeling. It is the model that ultimately describes the problem domain you are working in. Sometimes you will also hear the term persistent classes.
域模型一词来自数据建模的领域，它是你在工作中是最终地描述的问题领域模型。有时你也将会听到持久化类这个术语。
Ultimately the application domain model is the central character in an ORM. They make up the classes you wish to map. Hibernate works best if these classes follow the Plain Old Java Object (POJO) / JavaBean programming model. However, none of these rules are hard requirements. Indeed, Hibernate assumes very little about the nature of your persistent objects. You can express a domain model in other ways (using trees of java.util.Map instances, for example).
最终的应用程序域模型是ORM中的控制角色。它们组成了你希望去映射的类。Hibernate效果最好，如果你遵循普通的JAVA对象(POJO)/JavaBean 设计模型。然而，这些都不是硬要求。的确，Hibernate 承担地非常少关于你的持久化对象。你能够在其他方面表达域模型（例如使用Map实例树状结构）。
Historically applications using Hibernate would have used its proprietary XML mapping file format for this purpose. With the coming of JPA, most of this information is now defined in a way that is portable across ORM/JPA providers using annotations (and/or standardized XML format). This chapter will focus on JPA mapping where possible. For Hibernate mapping features not supported by JPA we will prefer Hibernate extension annotations.
从历史的观点来说使用Hibernate将需要使用它的专有的XML映射文件格式化为了这个目的(这里指格式化Model)，随着JPA的到来，大多数信息现在定义很便捷通过ORM/JAP提供使用注解(或者是标准的XML格式)。这章节将集中的JPA映射在可能的情况下。
2.1. Mapping types
Hibernate understands both the Java and JDBC representations of application data. The ability to read/write this data from/to the database is the function of a Hibernate type. A type, in this usage, is an implementation of the org.hibernate.type.Type interface. This Hibernate type also describes various aspects of behavior of the Java type such as how to check for equality, how to clone values, etc.
Hibernate 懂得Java和JDBC应用程序数据的表示。能读/写数据到/从数据库是HIbernate类型的功能。一个类型，这种用法是 org.hibernate.type.Type 接口的实现。
HIbernate类型也描述各种Java类型的行为方面，例如怎样去检查相等，怎样去克隆值，等等。
To help understand the type categorizations, let’s look at a simple table and domain model that we wish to map.
去帮助理解这个类型分类，让我们看一个简单的表，我们希望去映射域到模型。
In the broadest sense, Hibernate categorizes types into two groups: 
In the broadest sense, Hibernate categorizes types into two groups: 2.1.1. Value types
A value type is a piece of data that does not define its own lifecycle. It is, in effect, owned by an entity, which defines its lifecycle.
一个值类型是一个不能定义它自己的生命周期数据的片段，由一个实体，定义它的生命周期。 Looked at another way, all the state of an entity is made up entirely of value types. These state fields or JavaBean properties are termed persistent attributes. The persistent attributes of the Contact class are value types. 另一方面，所有实体的声明组成完整地值类型。这些声明属性或者JavaBean属性是持久化属性的术语。这个持久化Contact类的属性就是值类型。
Value types are further classified into three sub-categories:
值类型进一步分类为3个子类别：
Basic types
in mapping the Contact table, all attributes except for name would be basic types. Basic types are discussed in detail in Basic Types
Embeddable types
the name attribute is an example of an embeddable type, which is discussed in details in Embeddable Types
Collection types
although not featured in the aforementioned example, collection types are also a distinct category among value types. Collection types are further discussed in Collections
基本类型：
映射到Contact表，所有属性除了名字作为基础类型。
可嵌入类型：
名字属性是一个嵌套类型的例子。
集合类型：虽然不是在上面提到的特性，集合类型也是一个有别于值类型的分类。
2.1.2. Entity types
Entities, by nature of their unique identifier, exist independently of other objects whereas values do not. Entities are domain model classes which correlate to rows in a database table, using a unique identifier. Because of the requirement for a unique identifier, entities exist independently and define their own lifecycle. The Contact class itself would be an example of an entity.
Mapping entities is discussed in detail in Entity.
实体，通过它们唯一标识符的本质，独立于其他对象而值不存。实体域模型类关联到数据中的列，使用唯一的标识符。因为需要一个唯一标识符，实体存在映射实体的描述详情在Entity这一节里。
2.2. Naming strategies
Part of the mapping of an object model to the relational database is mapping names from the object model to the corresponding database names. Hibernate looks at this as 2 stage process:
- The first stage is determining a proper logical name from the domain model mapping. A logical name can be either explicitly specified by the user (using
@Columnor@Tablee.g.) or it can be implicitly determined by Hibernate through an ImplicitNamingStrategy contract. - Second is the resolving of this logical name to a physical name which is defined by thePhysicalNamingStrategy contract.
对象模型的映射部分关联数据库映射名字从对象模型到相应的数据库名字。HIbernate看着两阶段过程：
第一阶段是确定从域模型映射适当地符合逻辑的名字。使用一个逻辑名字能清楚的指定(使用@Column或 @Table e.g.)或者能 隐示的确定通过HIbernate的ImplicitNamingStrategy约定。
第二是解析逻辑名到物理名定义通过PhysicalNamingStrategy 约定。
历史的命名策略规约
历史上HIbernate定义只是一个单例org.hibernate.cfg.NamingStrategy。单一的NamingStrategy规约实际上结合分离了现在模式化的关注点如同ImplicitNamingStrategy和PhysicalNamingStrategy.而且NamingStrategy规约经常不够灵活去正确的应用给定的命名“规则”，也应为API缺少信息去判定或因为API太诚实不能很好定义。
由于这些限制，NamingStrategy曾弃用然后移除而赞成使用ImplicitNamingStrategy and PhysicalNamingStrategy
At the core, the idea behind each naming strategy is to minimize the amount of repetitive information a developer must provide for mapping a domain model.
中心思想，这个主意后面的每个命名策略信息开发者必须提供的映射域模型使大量的重复减小到最小。
JPA兼容性
JPA定义继承规则关于隐式逻辑名推测。如果JPA提供者可移植性是一个主要地关注点，或者如果你真的只是像JPA定义隐式的命名规则，那么可以坚持使用默认的ImplicitNamingStrategyJpaCompliantImpl 。同样，JPA定义不分离逻辑名和物理名字。如果JPA提供者可移植性是重要的，应用程序应该不去指定这个策略PhysicalNamingStrategy。
蛋疼的翻译。。。。云里雾里。。。。