今天和大家聊下关于数据建模和数据映射的事情，其实开始一个简单的项目的时候，我们的目标是很明确，而且所做的事情相对来说是比较简单的流程。
如果我们面向的是对象或者服务，一旦这个数量多了之后，就开始碰到一系列的问题，等到你发现系统在建设的过程中，还需要和外部系统对接，会对你已有的流程产生不小的影响。
在我的体会中，有几个主要的节点：
-
从原来的SQL模式切换为ORM的管理模式
-
从使用ORM模式切换为RESTful API模式
-
建设RESTful API模式，创建序列化类
-
创建自定义模型，匹配外部接口
-
数据和文件映射接口
-
自定义模型和ORM模型映射
对此我画了以下的图来说明。
我们从客户端，前端触发请求，使用Django的MTV模式时，映射到的是view层。
比如这里我们连接到的是一个view层，是一个用户管理的界面，那么我们可以对用户信息进行修改和删除，这个信息是存储在数据库层面的。
对于添加用户信息，我们可以使用一个原生的Django APi来完成，而对于修改的部分也是类似，同时我么也可以完全使用API模块来映射。API映射的部分可能有自定义的model或者是使用已有的ORM使用的model，这个的差别就在于，如果使用ORM的model时，整个的模型映射可以使用Serializer来实现，而对于自定义模型来说，这个过程是一个手工构建，或者我们使用第三方的模块来处理。这里的难点就在于自定义模型和Model的映射，因为我们对于数据的生效不只局限于API层面，还希望它能够持久化，保持数据的一致性。
上面的场景的适用范围是有一定的局限性的，比如我们换个场景，一个返货强信息生效的场景，这个时候防火墙的信息就会在几个层面，通过数据库层面生效，还有在系统层面生效，这样的过程是有一个顺序性的。我们可以设想为几类场景：
1）开通权限的时候，系统权限首先开通，然后数据库层面的映射生效
2）查看权限的时候，有限查看数据库层面的权限，如果不存在则查看系统层面的信息
3）对第一种场景优化，在数据逐步完善的前提下，我们优先在数据库层面生效，然后来自关联系统层面生效。
4）如果权限的信息是通过接口的形式来提供访问，则需要在本地维护一套cache.每次调用后缓存在本地，通过特定的规则和接口来达到数据的同步和更新。
5）更为复杂一些，对于部分属性的修改，从模型层面牵涉到更多的模型变更，这个部分就可以逐步的细化为流程或者规则，通过这种方式来达到统一的变更调配。
如此一来我们就可以实现一个看起来复杂的多位查看需求，比如查看一个用户在哪些服务器有指定端口的权限，在数据建设不完善的情况下，这种情况就是一个难题。
