以电子商务和医疗行业为例看b端工作台和消息系统的设计

工作台和消息系统是b端产品的两个必备功能，但它们并不是b端产品的核心功能点，因此常常被忽略。

工作台的主要目的是提供一些重要数据和服务的概述，而消息系统则是提醒诸如业务消息和系统消息之类的重要消息。在不同的应用场景中，两个系统的功能可能完全不同，也可能高度重叠。如何更合理地设计这两个系统？它既能满足用户的需求，又能节省开发成本。

本文以电子商务和医疗行业为例，除了从功能层面进行探讨外，还将带您了解技术解决方案，从而选择更加合理的实现方式。

一些系统中的工作台称为主页，概述。进入系统时，通常先跳转到此页，这是一个很大的集合。用户可以在这个页面上看到很多重要的信息概述。

这是一些电子商务的主页。我们可以看到这些页面上有很多内容，包括这些常用功能模块：

可以说，卖家关心什么，平台想推广什么，一目了然。但电子商务的业务处理场景相对简单，主要是订单处理的主线，而营销是他们的刚需，所以他们的主页大多是平台推广。

订单处理路径：

在医疗系统中，我们会发现工作台主要由待办事项、业务数据和常用功能快速链组成，基本上没有平台的营销推广。

待办事项的表现形式是不同的，不仅是一个总的统计，而且是每一项的详细情况。例如，等待分流、等待接待、等待回访客户等信息，以及相应的快捷操作按钮。

信息系统主要用于提醒和存储以下三个方面的重要信息：

在表示形式方面，通常有一个独立于页面的挂起消息列表，如下图所示。这允许您实时查看重要消息，而不会中断用户操作。

如果有更多的消息，一些系统会添加一个特殊的页面来承载所有的历史消息。

从上面的功能对比可以看出，工作台的重要提醒和待办提醒的内容可能会与消息系统的内容重叠，如果提醒更详细的话，甚至会出现高度重叠。这次你需要做两套吗？有可能分享一个计划吗？让我们先了解一下技术方案。

如上图所示，工作台上的总数量，例如要发货的数量3和要注释的数量5，实际上后面有一个统计中心。

增加待办事项，统计中心相应业务增加1项。相反，如果我们处理它并且状态改变，数量将减少1。例如，订单从挂起的付款状态更改为挂起的交货状态。前者增加1，后者减少1。

工作台以页面的形式显示，因此当进入此页面时，它将实时获取***的数据。此时，您只需要从统计中心获取值。不需要实时查询每个业务的状态，然后进行汇总计算。因为实时查询非常消耗性能，所以此页可能无法加载。

如果要在工作台上显示具体信息，需要在进入工作台时实时查询，如下图中的调度信息。此函数的数据较少。您只需在排程功能下直接查询当前账户信息，然后再显示出来，不会影响性能。

但让我们看看上面我的待办事项列表中的信息，它涵盖了系统的所有业务流程，以及很多预警通知。如果每个信息都是实时查询的，那么每个业务都需要一个查询接口。当这个页面上有20个业务类型时，许多接口将被卡住，严重影响性能。

所以有些系统会把这些内容分开。让我们看看这个数字。虽然有很多企业，但它们并不是一次性加载的。通过单击并切换选项卡，您可以一次查询一个业务的数据，这大大减少了性能问题。

这样做还有一个很大的缺点，就是不能一下子读完待办事项列表，必须逐个点击切换。它不像上面的卡片形式和完整的显示方式那样直观。如果你想用卡片的形式。我们应该考虑以下的实施。

这也是消息系统的实现。当业务场景被触发时，业务端将消息推送到消息系统，所有消息都集中在消息系统中。

例如，当患者注册时，要分诊的消息将发送到消息系统的分诊业务。护士将病人分开，并向信息系统的等待服务发送要接收的信息。同时，原始等待服务的消息被设置为已读而不显示。

在嵌入式点推的方式下，当工作台需要同时显示很多特定的业务内容时，只需要通过消息系统的一个接口获取。与之前的20多个接口相比，它解决了性能问题。

将这些消息（无论是已读的还是未读的）放入要显示的消息弹出窗口或页面中，这是我们在上面看到的消息中心。

但是，这种方式也有一个缺点，即当业务推送的消息很多时，需要每隔一段时间清空以前的消息，否则，数据库将无法承受压力和停机时间。

例如，在一个诊所里，一天的门诊量是100次。每位患者都要经历一次门诊流程，每天生成8条消息通知，800条消息。1000家诊所每天产生80万条数据。所以这些信息需要在3-4天内清除。

以电子商务系统为例。他的工作台和消息系统是完全独立的。工作台主要基于操作推荐，消息系统主要基于系统消息，没有交集。

在这种情况下，工作台的总数据（如待办事项）是通过建立统计中心来实现的。操作内容可直接从业务端获取。

消息系统是通过推来构建的。除了系统通知，它还可能包含一些业务消息，例如：您有新的订单，可以满足。

以医疗系统为例，工作台和消息系统有很多交集，我们不妨做一个融合的构建。

同样，通过建立统计中心来实现待办事项等总数据。但是，在显示待办事项的详细信息时，可以使用嵌入点的方法，这样在使用消息系统时，可以直接重用数据。

虽然我刚才说过，嵌入点的缺点是定期清理数据，但是对于一个业务流动性很高的系统来说，前几天的信息已经没有价值了。比如，今天有个病人来看病，提醒医生等治疗。即使医生今天没去看他，留言也留着，他第二天来的时候还是得再挂号。这位医生不愿处理历史新闻。

数据可以重用。这是否意味着只需要一页？每次有消息来，都要提醒你有新消息。点击进入工作台查看？

***不要这样做，因为当用户点击消息并想查看详细信息时，会弹出当前页面，这可能会中断现有操作，用户体验极为糟糕。建议在不影响用户操作的情况下添加固定的挂起消息列表。这个功能好像又重复了一遍，增加了工作量。实际上，这只是前端显示的工作负载。对于后端，共享一组数据可以节省成本。一般来说，这是一种成本效益高的方法。

工作台和消息系统有时似乎彼此无关，但有时它们看起来完全相同，这取决于业务本身。它可以查看其他系统，以及其他显示内容和形式。

它仍然是面向功能的，但是我们必须把***放在技术的实现上，因为无论功能多么***，如果我们不能使用它，它都是零。

在考虑技术实现的成本时，不要被眼前的景象所迷惑。了解背后的实施原则。这样，我们就可以把它们自由地放进放出来，让它们独立或融合，相互补充