一、产品分层的必要性
解决产品共性与个性的矛盾：标准产品统一的要求与行业、客户个性化的要求的矛盾；
解决产品扩展问题：将标准产品进行行业特色的扩展，进一步进行客户个性化的扩展；
利于重用：每层共性的东西抽象后放到下一层，服务于上层；
利于解耦：层次清晰，层间松耦合，产品可扩展性和可维护性高；
利于形成不同的解决方案，满足不可客户需求：在标准产品的基础上组合行业和客户层的功能；
利于行业产品向通用产品的转型：从众多的行业产品中抽象出共性的部分，将其下沉，逐渐丰富标准产品。
二、产品分层维度
1、产品的逻辑分层
1）分层原则
抽象原则：凡是本层共有的特性，应该抽象到下一层，能抽象的尽量抽象。
标准化原则：能标准化的尽量标准化，标准层的东西越多，说明产品化程度越高，系统越好维护。
增量原则：为了便于维护，每一层只保存本层特性的增量部分，不重复下一层的内容，以避免升级导致的重复修改。
低耦合原则：层间依赖关系是简单的接口依赖关系、不允许依赖实现逻辑；单向的依赖关系，且只允许上层依赖下层。
向下沉淀原则： 随着产品的发展完善，每一层具有共性的特性应该进行抽象、逐层下沉。
2）分层模型
由底层到高层：
支撑层->标准层->行业层->客户层->自定义层
支撑层：由所有业务模块的共性抽象而来，适用于所有业务模块的特性放在这一层，这一层也是模型的最低层，技术框架、公共组件和通用服务。
标准层：由所有行业功能的共性抽象而来，适用于所有行业的功能特性放在这一层，各产品模块的标准功能都属于这一层，这些标准功能是适用于所有行业和所有客户的。
行业层：仅适用于特定行业的功能特性放在这一层，各产品模块的行业功能特性属于这一层，这些功能体现了行业特色，且适用于该行业的所有客户的。
客户层：仅适用于特定客户的功能放在这一层，各产品模块中针对特定客户的功能特性属于这一层，这些功能是这些客户特有的，不适用于其他客户。
自定义层：为客户定制的功能或者实施地定义的功能属于自定义层，这一层不属于产品的范围，模型中出现此层仅为说明自定义部分与产品部分的界限。
每一层都是本层特性的集合，是基于下一层特性的新增、修改或屏蔽。
2、产品的结构分层
1）分层原则
MVC原则：模型-视图-控制器的模式构建程序。
接口实现分离原则：接口与实现分开为不同的工程项目。
DAO原则：单独的工程项目作为数据访问的载体。
2）分层模型
由底层到高层：service->dao->impl->web
3、产品的数据分层
1）分层原则
空间分离原则：客制化需求数据存储空间与GRIS数据存储空间分离。
用户分离原则：不同数据存储空间的访问用户独立创建。
权限分离原则：数据库管理权限与数据库操作权限分离，限制数据库用户越权使用和部分跨层操作。
业务领域(数据主题)部署划分原则：业务领域支持分用户分库，实现产品按数据主题解耦部署。
单向依赖原则：支撑层、产品标准层、行业层、客户层、自定义层等（层次自下而上）数据实体单向的依赖关系，且只允许上层依赖下层。产品各层内各业务领域间关系实体只能归属到一个业务领域，并实现单向的依赖。
2）分层模型
由底层到高层
平台支撑层->产品标准层->行业行业/客户层->定制层->开放交互层
平台支撑层：技术平台与业务平台的数据。
产品标准层：对应于“逻辑分层”中的标准层内容的数据。
行业行业/客户层：对应于“逻辑分层”中的行业层和客户层的数据。
定制层：对应于“逻辑分层”中的自定义层的数据。
开放交互层：用于与外界交互的数据
