系統通知公告通常有系統因業務狀態變化自動發起的通知公告和管理人員通過后臺管理主動發起的通知公告。如果是因業務狀態自動發起的通知公告，那么其發送的渠道需要結合業務需求，在編碼時確定。如果是管理人員通過界面發起的通知公告，那么需要在配置界面提供可選擇的渠道，根據業務需求由發起人來確定通過哪些渠道發送。
系統的通知公告功能似乎是很容易被忽略的功能模塊，在傳統的軟件系統中，一般OA類軟件系統不可或缺，而在應用軟件系統中此功能或有或無，在現在大多數的互聯網軟件系統中，此功能又必不可缺。所以，在框架設計時，我們需要考慮業務系統是否需要此功能模塊，然后將此功能作為擴展插件，在需要時開啟，在不需要時配置關閉即可。
在系統公告設計之前，我們需要綜合考慮目前系統通知公告功能都有哪些類型和實現方式。在類型方面如果是電商類網站，那么系統的通知公告有賬戶變動通知、物流變動通知、訂單變動通知等等；如果是OA類系統，那么系統的通知公告有待辦事項、審批通知、公司公告通知等等；在實現方式方面，有站內通知、短信通知、微信通知、APP推送消息等等。
在通知公告的來源和通知公告的目標方面也要做好區分，通常的通知公告來源有系統通知、群組通知、用戶通知；相對于通知公告的目標方，有群組、角色、用戶等分類，下面是通知公告功能關鍵表的E-R圖，不包含RBAC模型關系，框架支持多租戶：
1、系統公告來源
系統通知：來源于某一個功能模塊或者統一抽象為系統消息，比如賬戶異地登錄、密碼嘗試次數過多等，這些顯示來源于系統消息即可；如果是告警等需要詳細的來源時，比如微服務模式下每個服務所引發的告警等信息，這里需要標識具體的系統來源模塊。
群組通知：來源于某一個部門的的消息，有些消息內容是由部門來統一發出，比如考勤、放假等通知由行政部門發出，薪資等相關內容由財務部門發出。
用戶通知：由某一個人發出的通知公告，此種情況使用比較少，區別于用戶對用戶的私信消息，用戶私信功能需要和系統通知公告功能做好區分。
數據庫表設計公告通知來源字段：
`message_category` VARCHAR(32) COMMENT '系統公告 待辦消息 賬戶通知 關注/收藏/點贊通知' ,
`receive_type` VARCHAR(32) COMMENT '接收消息類型 全員 組 角色 用戶' ,
`to_organization_id` BIGINT(20) COMMENT '接收消息的群組' ,
`to_role_id` BIGINT(20) COMMENT '接收消息的角色' ,
`to_user_id` BIGINT(20) COMMENT '接收消息的用戶' ,
2、系統公告目標
群組目標：某一公告通知是針對于群組的，就是某一個部門內的人才能夠收到的消息。
角色目標：針對于角色的通知公告，比如某一條通知公告是只發送給公司內部所有的部門經理的。
用戶目標：這個比較好理解，針對個人的消息通知，比如自己的請假申請或者報銷審批通過等，系統需要發送消息到個人。
數據庫表設計公告通知目標字段：
`send_from_type` VARCHAR(32) COMMENT '消息來源類型 系統 組 用戶' ,
`from_group_id` BIGINT(20) COMMENT '發送消息的組' ,
`from_user_id` BIGINT(20) COMMENT '發送消息的用戶' ,
`from_system` VARCHAR(32) COMMENT '發送消息的系統' ,
3、系統公告級別
系統通知公告可以根據情況設置通知公告的級別，比如高、中、低，那么在前端提醒的方式就可以采取強制彈框、靜默提醒等方式來處理這些通知公告。如果是定時發送，那么需要設置定時任務根據發布時間來定時發送；如果有消息撤回，那么需要標識已撤回以及消息撤回時間。
數據庫表設計通知公告級別和發布時間字段：
`publish_time` DATETIME COMMENT '發布時間' ,
`recall_flag` TINYINT(2) COMMENT '是否撤回' ,
`recall_time` DATETIME COMMENT '撤回時間' ,
`message_level` VARCHAR(32) COMMENT '消息級別 高 中 低' ,
4、系統公告附加內容
有些系統的公告通知可能不只是文本消息，基于用戶體驗考慮，有些消息到達時，用戶可以直接通過點擊通知跳轉到具體的業務處理模塊，比如工作流的待辦事項、未支付訂單的提醒等等。在現在的APP推送消息中，甚至可以設置消息通知的縮略圖，那么我們在數據庫表設計的時候也需要把這些情況考慮進去。
數據庫表設計通知公告附加字段：
`title` VARCHAR(100) COMMENT '標題' ,
`content` VARCHAR(1000) COMMENT '內容' ,
`redirect_url` VARCHAR(255) COMMENT '跳轉鏈接' ,
`image_url` VARCHAR(255) COMMENT '消息圖片' ,
......
`publish_time` DATETIME COMMENT '發布時間' ,
`recall_flag` TINYINT(2) COMMENT '是否撤回' ,
`recall_time` DATETIME COMMENT '撤回時間' ,
`message_level` VARCHAR(32) COMMENT '消息級別 高 中 低' ,
5、系統公告通知渠道
現在移動辦公越來越普遍，針對于移動客戶端的多種方式，那么我們在發送通知公告時的渠道也是需要有配置的，比如發送到PC端、APP端、微信小程序端、微信公眾號通知、短信通知、電話通知等等，有可能是一種，也有可能是多種，那么此時我們需要為通知公告增加不同的通知渠道。由于是不定數量的渠道，所以這里我們增加關聯表，來為某一條通知公告設置通知渠道。默認如果不配置渠道，那么都是靜默通知，不彈框也不APP推送。
數據庫表設計通知公告通知渠道配置表：
CREATE TABLE t_sys_message_channel(
`id` VARCHAR(32) COMMENT '主鍵' ,
`tenant_id` BIGINNT(20) COMMENT '租戶id' ,
`message_id` VARCHAR(32) COMMENT '系統消息id' ,
`message_channel_type` VARCHAR(32) COMMENT '渠道類型（短信、電話、APP PUSH等）' ,
`channel_redirect_url` VARCHAR(255) COMMENT '本渠道的跳轉鏈接' ,
`channel_image_url` VARCHAR(255) COMMENT '本渠道的圖片' ,
`creator` BIGINNT(20) COMMENT '創建者' ,
`create_time` DATETIME COMMENT '創建時間' ,
`operator` BIGINNT(20) COMMENT '更新者' ,
`update_time` DATETIME COMMENT '更新時間' ,
`del_flag` tinyint(2) COMMENT '是否刪除'
) COMMENT = '通知渠道和系統消息關聯表';
6、系統公告表優化
除了完成基本的內容表設計時，我們還需要考慮數據量非常大時的數據庫設計優化問題。在我們的通知公告中，我們發現有很多消息是通用消息，是發送給群組的、角色的，這類消息的內容是一致的，如果為每個用戶都新建一條這樣的通知公告數據庫記錄。那么會冗余很多無用數據。但是，我們又需要針對群組、角色中的某一個用戶標識出通知公告的已讀/未讀狀態等內容，所以此處需要增加關聯表，利用關聯表來標識某一個用戶是否讀取了消息。
數據庫表設計通知公告某一用戶的狀態字段：
CREATE TABLE t_sys_message_user(
`id` VARCHAR(32) COMMENT '主鍵' ,
`tenant_id` BIGINNT(20) COMMENT '租戶id' ,
`user_id` BIGINNT(20) COMMENT '用戶id' ,
`message_id` VARCHAR(32) COMMENT '系統消息id' ,
`read_already` VARCHAR(32) COMMENT '是否已讀' ,
`creator` BIGINNT(20) COMMENT '創建者' ,
`create_time` DATETIME COMMENT '創建時間' ,
`operator` BIGINNT(20) COMMENT '更新者' ,
`update_time` DATETIME COMMENT '更新時間' ,
`del_flag` tinyint(2) COMMENT '是否刪除'
) COMMENT = '用戶和系統消息關聯表';
通知公告主表完整建表腳本:
CREATE TABLE t_sys_message(
`id` VARCHAR(32) NOT NULL COMMENT '主鍵（雪花算法）' ,
`tenant_id` BIGINT(20) COMMENT '租戶號' ,
`title` VARCHAR(100) COMMENT '標題' ,
`content` VARCHAR(1000) COMMENT '內容' ,
`redirect_url` VARCHAR(255) COMMENT '跳轉鏈接' ,
`image_url` VARCHAR(255) COMMENT '消息圖片' ,
`message_category` VARCHAR(32) COMMENT '系統公告 待辦消息 賬戶通知 關注/收藏/點贊通知' ,
`receive_type` VARCHAR(32) COMMENT '接收消息類型 全員 組 角色 用戶' ,
`to_organization_id` BIGINT(20) COMMENT '接收消息的群組' ,
`to_role_id` BIGINT(20) COMMENT '接收消息的角色' ,
`to_user_id` BIGINT(20) COMMENT '接收消息的用戶' ,
`send_from_type` VARCHAR(32) COMMENT '消息來源類型 系統 組 用戶' ,
`from_group_id` BIGINT(20) COMMENT '發送消息的組' ,
`from_user_id` BIGINT(20) COMMENT '發送消息的用戶' ,
`from_system` VARCHAR(32) COMMENT '發送消息的系統' ,
`publish_time` DATETIME COMMENT '發布時間' ,
`recall_flag` TINYINT(2) COMMENT '是否撤回' ,
`recall_time` DATETIME COMMENT '撤回時間' ,
`message_level` VARCHAR(32) COMMENT '消息級別 高 中 低' ,
`creator` BIGINT(20) COMMENT '創建人' ,
`create_time` DATETIME COMMENT '創建時間' ,
`operator` BIGINT(20) COMMENT '更新人' ,
`update_time` DATETIME COMMENT '更新時間' ,
`del_flag` TINYINT(2) NOT NULL COMMENT '是否刪除' ,
PRIMARY KEY (id)
) COMMENT = '消息通知表';
系統通知公告通常有系統因業務狀態變化自動發起的通知公告和管理人員通過后臺管理主動發起的通知公告。如果是因業務狀態自動發起的通知公告，那么其發送的渠道需要結合業務需求，在編碼時確定。如果是管理人員通過界面發起的通知公告，那么需要在配置界面提供可選擇的渠道，根據業務需求由發起人來確定通過哪些渠道發送。
源碼地址:
Gitee:https://gitee.com/wmz1930/GitEgg
GitHub:https://github.com/wmz1930/GitEgg
