系統的通知公告功能似乎是很容易被忽略的功能模組，在傳統的軟體系統中，一般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 = '訊息通知表';
系統通知公告通常有系統因業務狀態變化自動發起的通知公告和管理人員透過後臺管理主動發起的通知公告。如果是因業務狀態自動發起的通知公告，那麼其傳送的渠道需要結合業務需求，在編碼時確定。如果是管理人員透過介面發起的通知公告，那麼需要在配置介面提供可選擇的渠道，根據業務需求由發起人來確定透過哪些渠道傳送。