前言
时代变了。
以往数据更多的通过人工录入，从专用网络协议的终端转移到“玻璃房子”里的大铁盒子，现在信息无所不在、无时不在，不过不一定都会汇总到您公司里，很多时候大家是在一个“平”的世界里分享数据，信息来源的渠道多了、信息本身的变化也更加频繁。不仅如此随着Web 2.0、Enterprise 2.0和Internet Service Bus等一系列概念的出现，您发现单单从自己的“玻璃房子”里找供货商提供的仓库地址远不如Google Map方便。
似乎以往桎梏数据的各种枷锁在互联网下被一一打破，但作为IT从业者，我们的工作是为用户提供它们所需的数据和他们希望获取信息的手段，因此应用必须能够经得起各种变化，包括以往我们关心的用户界面的变化、应用间调用的变化、应用内部逻辑的变化，还有步伐越来越快但又是最根本变化——数据自身的变化。
关系模型告诉我们要用二维表格描述信息世界，但这是太“不”自然不过了，看看手边的一本书或是家里的装修计划、马上要开工项目的任务分解，好像套到一个二维表格里总不合适，而且即便通过“实体——关系”生硬的削足适履后，在快速变化的环境下又总是要牵涉到“数据——应用——前端交互”一系列变动，而且经常是牵一发动全身。
似乎很多新一代应用已经找到了更适合新趋势的方案——XML，用一种更贴近我们自己思维的方式组织应用、组织用户体验。那么对于企业而言，组织数据这种相对基础性的工作是否也可以用XML的思维进行呢？应该可以。
应对数据实体自身的变化
数据实体以往总是被假设为应用中最为稳定的部分，无论我们用设计模式还是采用各种开源的开发框架（包括这些框架本身）都是尽量在适应应用本身变化的问题，那么现实的情况如何呢？
l 我们需要交换的数据实体经常要根据自身、合作方的需要变化；
l 合作方给我们的数据实体也常常变化；
l 随着SOA和Enterprise 2.0概念的推出，数据实体本身从多个源mash up出来，同时数据实体本身也被反复的拼装和组合；
l 随着业务的细化，我们自己的员工总是希望获取越来越丰富，同时也越来越详尽的信息；
因此，以往视需求也好、设计也好认为可以最早固定下来的数据实体在愈发敏捷的技术和业务现状前需要不断调整。为了适应这个要求我们可以自顶向下入手，不断调整应用自身的柔性；另一个方式是从“根”上处理这个问题，采用自身就可以不断适应这些变化的新数据模型，例如：XML数据模型和XML相关技术家族。
例如，定义用户实体的时候，最初下面的信息就够了，其中ICustomer是应用会使用的用户接口，而CUSTOMER为关系数据库方式下的表示，<Customer>为XML方式：
