記得阿朱在《走出軟件作坊》一書中有一章講客戶提的需求太邪門了，鼠標鍵盤不太會用要程序員開發一個語音輸入功能，還要系統中帶類似QQ的功能；確實剛開始的客戶的想法有點天真，但是隨着信息化的越來越普遍，客戶對信息系統也比較了解，特別年輕的信息管理人員，除了接受能力強，並且長期站在客戶的角度對信息系統也有一些獨特的見解，跳出技術框框外的想法；
其中有個年輕的信息人員聊天的時候說了一些對系統的要求，其中有一個功能是這樣的，部門人員向庫房申請一批物資，以前的做法就是先把申請單內容錄入系統，然后再電話通知庫房人員叫他們審核申請單，審核完后核對沒有問題，庫房人員再打電話通知他們什么時候送貨過來；現在聽了他的意見改進后，部門人員錄完申請單，保存的時候系統自動發送一條消息給所有庫房人員，庫房人員的電腦會彈出一個類似QQ的通知框，庫房人員就會馬上審核此申請單，然后審核完成后，系統又會自定生成一條消息發給接收部門；全程再也不需要電話聯系，系統給人帶來一種比較智能的感覺；
當然他跟我講得並不止這一點點，如申請也不應該由他們自己錄入，應該是系統自動給他們生成，還有系統很多環節不應該是由人作為事件的開始點，應該由系統主動的做出判斷並提醒操作人員應該做什么，還有哪些事需要做；我最后的感覺就是以前的系統只是一個單純的工具，操作人什么時候要用就拿過來用一下；而以后的系統應該更智能，從被動的接收變為主動的提供工作上的指導，實時促進崗位上人員的工作；從被動的信息傳遞到主動的信息分析；
又跑遠了，本章內容是講框架中的“消息管理”模塊，當然此功能肯定沒有上面說的那么神，其實就是一個簡單的短消息功能，與業務系統的緊密集成，實現業務出現多崗位的時候能夠實時的發送消息給對應的人員；把消息類型的管理與消息的推送封裝成一個公共的模塊；而消息什么生成與生成什么內容就需要深入的分析業務建立相關模型了；
本文要點：
1）功能清單介紹
2）功能界面展示
3）核心業務流程圖與數據庫表關系圖
4）關鍵點的技術實現代碼
1）消息管理功能清單
| 模塊名稱 |
功能名稱 |
功能說明 |
| 系統消息 |
消息類型設置 |
消息類型維護，新增、修改、停用 |
| 消息記錄管理 |
查看消息，未讀、已讀、已發 |
|
| 消息實時提醒 |
產生新的消息，推送給用戶，主界面給出提示框 |
2）消息管理界面展示
3）消息管理業務流程與核心表
4）消息管理關鍵技術實現
1.消息的兩種模式
看上面兩張業務流程圖，模式一消息類型定義好用戶角色，模式二用戶自定義訂閱自己的消息；模式一適合崗位非常固定的企業，消息推送按照配置好的角色就行了；模式二適合一人多崗，崗位人員比較靈活的那種，因為崗位靈活如果按照模式一的方式，那此人可能時時刻刻都會受到消息的騷擾，應該上午做這個事，那么就應該只推送這個事的消息就行了，下午就推送下午的消息；所以需要用戶自己維護自己的消息接收時間和內容；
2.產生消息的統一接口