数据推送
最早开始做项目时候，没有考虑到数据推送的问题，但是后来时不时的出现了很多。虽然这个模块可以独立出去，但是由于产品还是技术领导，都没有对他足够的重视，所以做为做的很混乱。
在这提出几个应该注意的地方。其实数据推送可以参考消息队列的设计思想。跟业务无关，异步发送，失败的不长机制
l 异步
这个主要是因为数据推送一般是推送到其他的项目中，所以可能会出现延时或者网络中断以及对方不在线等各种问题。所以如果是同步发送，那么接口的响应时间会很长。
l 补偿机制
可以分为自动补偿和手动补偿。比如定时扫描的方式，或者人工界面查询失败记录，手动点击发送。
l 不跟业务耦合
数据推送应该和业务没有关系。不应该和业务代码紧紧的耦合。
我们的项目基本完成后 ，才把数据推送提出来。而且是想起哪里，就在哪里加。虽然我写了一个公共的数据推送的接口，但是由于最开始是给一个模块设计的，所以接口设计的很有局限性，到后来各种模块都要公用，结果各种加字段，最后搞得很乱。
而且因为是后来仓促加的字段，来兼容各种模块，所以要做手动补偿，很难。字段太多太乱，每个模块传入的数据都不一样，导致没法正常显示。
其实这个最好在设计项目时候，就应该考虑清楚，哪些是需要推送的，提前做好准备。而且应该根据各个模块的情况，制定出一个兼容的方案，同时考虑好补偿机制。
在这提出自己的一个想法，事件触发和观察者模式的运用。
当一个模块中的一个数据改变后，触发A事件，A事件的代码里将新的数据拿出来，然后传送给所有在观察这个数据的地方。可以让其他业务线自己注册，注册自己需要监听的数据。这样会简单很多。
站内消息
这个模块是另一个同事做的。做的很乱。消息的类型是在程序里写死的，接收的角色也是写死的。导致之后再添加别的消息，就得重新改代码。
借鉴经验，个人认为消息模块应该是很灵活的模块，而且也是相对独立的。
首先消息的基本属性，标题，内容，类型可选。
然后消息的发送方，一般是系统自动发送，或者管理员发送的，或者是某个人发送的。相对比较具体。
主要是接收方，需要注重设计。如一下几种情况：
l 个人。最好处理
l 角色，只有一个人处理。只存在一条消息，任何人处理了，其他人都不用再处理。
l 角色，每个人都要处理。相当于群发了一部分人。此时要和用户表关联，每个人发一条消息。
l 群发所有人
可以有两种解决方式。一种是给每个人都发送一条。或者是特殊处理，让每个人都看到这个消息。但是要记录已读状态。
主要的字段参考：标题，类型，内容，发送人，发送时间，发送给角色还是个人，已读状态，已读时间。
其他可参考：即使发送/延时发送
用户，登陆和权限
用户-角色-权限
模块库隔离
模块内部关联，模块之间数据库隔离
数据库设计
除了业务字段，最好再加上记录创建/更新时间，创建人，
对也业务的每个行为，都应该对应数据的一个表示状态的字段，比如新增，审核等。
数据逻辑和业务逻辑分层
在项目做的时候，有些模块做了很多业务限制，比如新增报单，停用启用等。这些功能是给分中心用的，产品也没设计关于角色和权限的考虑。然而项目完成了，新需求来了，要求客服有最大权限，可以操作任何功能。于是就傻眼了，之前的代码里层层限制，现在怎么办。
所以现在想来，应该在业务层再分为两层，底层是纯数据层。操作这个功能所有的数据处理，不考虑业务的限制。然后在上层做限制，再根据业务需要，开发出多个业务接口，提供给不同的角色使用。
