web应用和移动app中，通知系统是一个独立并且重要的功能。为了规范化，也为了重用，我们把通知和站内信做成一个独立的服务，在开发中统一调用。需要说明的是，我这里考虑的主要是强关系的应用型系统，至于弱关系的系统处理起来可能略有不同。
分析
统一概念
消息的分类方法仁者见仁智者见智，根据我的理解分为系统消息（公告和应用产生的消息），用户之间的消息，动态。
系统消息：管理员发通告（没把管理员当人)；应用产生的提醒。
用户之间：私信（暂时不做，以后直接用im来实现）。
动态：动态和应用产生的消息有什么区别呢？为什么分开呢？我想主要是为了降低噪音，尤其对于应用型而言，有些动态对于用户来讲意义不大，而消息我们认为用户需要处理。如果是若关系型，两者可以合二为一。
通知的分类
如果是弱关系，例如sns的评论等，处理不处理没有任何关系；但是如果是强关系，例如关注、邀请或者oa的审批通知，如果不处理业务就停止了。对于这两种类型的通知如果混在一起，对于应用型的系统会有问题。但是如果用两个业务处理，无疑会很麻烦。所以在通知中增加分类，由应用来决定如何处理。
通知的订阅
[x] 免打扰------------------------------不影响收到消息，只是没有声音或者弹出气泡。
订单类 微信 邮件 短信
订单审批 [x] [x] [x]
订单出库 [x] [x] [x]
...................
通知的方式
用户得到通知的方式大致分 web、微信、短信、电子邮件、移动app、浏览器（谷歌）几种，根据用户的使用习惯，我们会支持web、微信、短信、移动app。v1我们主要考虑web和微信。
1、web
是最基本的，浏览器应用内默认的方式。
2、微信
一个应用会对应一个微信公众号，用户绑定微信后，可以收到微信消息。
技术处理
通知的聚合
聚合是一个技术活，如果消息量很大，那么聚合将会更加困难。聚合包括给某个人一个对象的消息合并成一条，例如张三、李四、王二评论了你的xxx消息；也包括一个人对你发的多条消息，张三给您发了n条私信。
思考再三，算了吧...
通知的用户处理
消息到达用户是第一，然后就是用户如何处理消息。如果是弱关系，那么点击了，就处理了；如果是强关系，需要一个动作表示已经处理完了，这点有点墨迹，但是对于应用型的系统而言还是有必要的。而且我想再墨迹一点，还要增加待处理状态。
未读->已读
未读（已读）->待处理->已读
点击就认为是已读；对于未读和已读的可以标记微待办理。即保证了用户操作的简单，又满足一些有条理人士的需求。
要有批量设置，给懒又有洁癖的人一个选择。
通知推送的技术选择
web
常用方式是轮询、长轮询、长连接。v1用轮询就可以了，实现简单，我们大部分应用都是面向B的，用户量都不大。
以后的章节为：UI设计（二）、对象设计（三）、数据库设计（四）
