参考
总结关键：
- 产品 SaaS 化输出的关键是如何对不同的用户通过标准+扩展能力按需进行算力、数据、安全、功能有效定制，支持多用户共性和个性的问题，即多租户的问题，同时也涉及到计费和服务水平等相关问题。
一般数据模型分为标准对象、用户自定义对象；前者解决多租户业务共性问题，后者解决多租户业务个性问题。
- 平台业务系统的逻辑模型到物理模型的直接映射是造成问题的主要因素。既然物理模型的变更是平台不稳定的动因，那么我们是否能通过解耦业务逻辑模型和物理模型的映射关系来尝试解决这个问题呢？
既然问题已经定义清楚了，如何解决这个问题呢？通常我们解决架构问题的一个“万能”的方法是：增加一个层次，我们也来套用一次，增加一个层次（元数据层）来解耦逻辑模型到物理模型强映射的问题。
首先，我们需要对业务进行建模，对业务进行抽象，定义出业务逻辑模型，然后对模型进行二次抽象，定义出逻辑模型的定义数据，实现业务模型的数据化，即模型的元数据(The Metadata of the Logic Model )，将模型结构存储为数据，而不是直接对应的物理存储结构。
其次根据定义出的元数据进行统一抽象，形成元数据逻辑模型。
将元数据逻辑模型映射到元数据物理模型，对应实际存储结构。
通过对业务模型的变更，形成对元数据层的数据变更，而不是物理结构的变更，从而实现业务逻辑模型同物理模型的解耦。
我对元数据驱动的理解
- 是什么？
- 有什用？好处？意义？
是什么
就是将业务逻辑模型的结构存储为数据，而不是直接映射为物理存储结构（如数据库表）。
直观点说明，采用元数据驱动的话，新定义表和新加表字段实际上都是往元数据表新增记录，这条记录就是描述新表或新字段的逻辑结构，并不会在物理层面新建一张数据库表或新增一个表字段。
采用元数据驱动，数据模型就有：元数据表、数据表；前者存储业务逻辑模型的结构，后者存储业务逻辑模型实际数据。
元数据表如：
- Objects表，存储对象信息
- Fields表，存储对象字段信息
有什么用
解耦业务逻辑模型和物理模型的映射关系，业务逻辑模型不再直接映射为实际的物理模型，保证了物理模型的稳定。
