作者从项目实践出发，对OA办公系统中如何发布公告进行了分析复盘■■，并从多个方面对关于公告的相关概念和功能进行了拆解，与大家分享。

　　这样来看，大部分OA中的“公告管理”其实是“通告管理■◆◆■”，但是为了不那么◆◆■“钻牛角尖■◆★”通常会统一叫做“公告管理”，方便直面理解。在此次OA的公告中★◆■■★■，也是将其作为了两种不同的公告样式。

　　当然服务端缓存机制也有若干种类■★，如redis、服务端内存 等，这里也不再展开讨论，根据公司实际情况暂定一种即可。

　　公告正文就主要是公告的主体信息★◆，包括主题■★★◆、发布者、正文内容等信息。在正文部分其实也暗含公告的种类■◆，目前使用较多的为两类：

　　既然采取了以时间换空间的方案★★◆■■★，就要想办法优化相关的处理，好在在B端产品中★■，很多业务场景会常用到组织树的查看，所以可以在这方面进行一定的存储查询优化：

　　是指政府★◆■■、团体对重大事件当众正式公布■◆，一种行政公文。它有三大特性◆■■：庄重性、广泛性和周知性。

　　已阅情况的查看，个人认为是个低频的，所以就废弃了已阅接收表这样的快照,采用了第二种【查看已阅情况时动态组织】的以时间换空间方案。这样做的好处是节省了保存已阅人员的空间★◆，当然带来的坏处就是过期的公告想回顾历史时无法回顾，只能看到当前的组织结构情况，这项决定的决策点就在于预判企业是★★■“向前看”还是“向后看”■★◆。而且就算有了快照，对于公告来说，在其有效期内若是组织结构发生了变动，而此快照想要精确的变动要素就要追加★■■■◆★。

　　管理公告主要管哪些？对于公告管理模块可能管理内容很多■★，但是当我们聚焦一条公告信息，则主要管理的有三部分★■◆★：

　　其中被动推送提醒◆■，主要是指用户在登录时，收到的系统级公告推送。一般是在新公告发布时的即时推送，或是用户初始登录，推送离线期间发布的公告★■★◆■。而主动查看公告提醒，则是用户在相关的门户页，查看到的相关未读公告列表。一种是■★■★“推”式，一种是“拉★★◆■◆★”式。

　　以上的逻辑控制只是决定了“谁能看”■★★■◆，但是对于公告接收者“能看哪些公告◆■■”这层业务逻辑没有回答。“能看哪些公告”主要是关注“能看哪些过期公告■■”。

　　这是一条不定的业务逻辑，不同的公司业务规则不同■◆★■，比较理想化的是——在公告管理时就有相关的配置项进行业务规则设定【新用户是否可查看过往公告】，亦或是其他的业务规则设定，这里就不再展开讨论■★。

　　除了上述的一些公告核心业务处理，还需考虑到公告除了自身本身是个独立业务◆◆★，它也是信息数据的载体。除了公告模块自己可以发布公告◆★◆◆◆，其他业务也可以搭载【转为公告】★◆，而此功能仅是用于快捷化填充公告的主体信息◆◆■★★■。

　　普通公告基本就是由公告正文构成，种类就比较多了，这里就列举下通用模板★◆■★■：

　　一个业务的构成往往是：一定组织（若干角色），经过一套流程，完成一定的事（处理一定数据载体）

　　一个公告的有效期范围是【2020年1月1日 ~2020年1月3日】，发布对象为【全体】可看。在1月5日创建了一个新用户，此时该新用户是否可查看此条公告？

　　简单的四个字“公而告之■★★◆◆”■■■★。作为信息化系统◆■◆◆，公告是可以作为一种信息数据载体，然后通过“之”限定范围已达到信息输出和反馈的目的。相对于普通的即时信息，最重要的一点就是它具有庄重性。