医疗场景交易平台战略设计&战术落地思考

需求整理

背景

问诊平台可以看作是电商场景下的交易平台,患者是买家,医生是卖家,医生的排班可以看作是库存,医患沟通可以看作是物流。
问诊平台的愿景是打造线上“一站式诊疗服务”,实现线上就诊场景的闭环。

image.png

核心子领域

  • 订单操作管理
  • 排班管理
  • 医生接诊资质管理
  • 医生接诊
  • 用户反馈(评价、投诉)
  • 医患交流
  • 治疗方案
  • 医生结薪

除了这些核心子领域外,诸如医生管理、支付管理、会员管理、健康档案管理等都属于通用的子领域,每个核心子领域都需要调用这些子领域提供的功能。注意,通用子领域提供的功能虽然不是系统业务的核心,但缺少这些功能,业务却无法流转。之所以没有将其识别为核心子领域,实则是通过对问题域的理解分析得来。
医生接诊资质管理是隐含的一个领域概念,医生接诊资质管理的支撑上游是医生组的医生接入管理领域。随着需求的迭代,发现需要支持渠道的订单权限个性化、需要考虑医生兼职和多职业点场景,这些需求是医生接入管理不会涵盖的,可以理解为医生接诊资质的管理。

业务流程

协作示意图

这个协作示意图非常清晰地体现了患者需求与医生能力之间的关系,展现了这个核心流程的关键环节。
问诊平台的核心是订单,订单的核心是订单状态的流转,下图是整理的订单状态流转图:


订单状态图

下面绘制出整个问诊系统的主流程:


问诊流程

需求细化

根据业务期望与愿景确定项目的业务范围,明确史诗级故事和主故事。在概要设计阶段要准确地把握“故事(Story)”的粒度,不至于沉入到过分细粒度的需求实现细节,影响了先启阶段的对问题的理解。故事的层次(粒度)并没有固定的标准,在先启阶段的需求分析过程中,使用用例来表述领域场景是一个很好的选择。恰好在 Cockburn 的著作《有效编写用例》中,他提到用例的层次包括:概要目标、用户目标和子功能。例如:


image.png

这里的用户目标就代表着具有业务价值的领域场景,也就是我们需要识别出来的主用例,它由多个子功能组成,它们之间的关系就是主故事与用户故事之间的差别。

用户侧

image.png

医生侧

image.png

几个注意点
1、理论上所有医生都应该要有号源限制,排班不仅限于专家医生,全科医生、药诊店医师其实也是有号源有排班。
2、开关是一种二进制,可以对开关进行归类,没必要一个开关一个字段,一个字段每一位可以表示为一种开关。

歧义概念明确定义

全科:“xx医院”下面的全科科室
全科订单:用户下了不指定科室的订单
:拥有独立展示层的应用,比如andriod、ios、支付宝引流h5、xx公司h5引流
渠道:拥有独立订单来源的端组合,这组端可以定义统一的订单权限,控制对哪批医生可见。渠道后面对应医疗资源。
租户:独立承载资源费用的主体,租户之间是资源逻辑隔离的,租户是微医云问诊平台作为PaaS承载的用户。

核心模型设计

整个系统架构风格--CQRS

命令查询的责任分离Command Query Responsibility Segregation (简称CQRS)模式是一种属于领域驱动设计(DDD,Domain Driven Design)的架构体系模式。在客户端就将数据的新增修改删除等动作和查询进行分离,前者称为Command,走Command bus进入Domain对模型进行操作,而查询则从另外一条路径直接对数据进行操作。
CQRS架构和公司数据层读写分离的整体架构相互呼应。目前公司采用基于开源软件Atlas的读写分离架构,一主多从的架构,DML操作默认路由到主库,DQL操作路由到从库。采用读写分离架构,主从延时的问题不可避免。如果查询和操作没有物理分开(复用的方法),那么为了保证10%不到的DML场景流量的数据一致性,就必须在SQL层进行强制走主(/master/)指定,这会导致流量都走到主库上了,从而导致主从架构形同虚设。
采用CQRS架构后,针对DML场景下的数据查询,可以采用单独的强制走主Sql,保证主从的流量的合理性。当然也可以使用采用我写的读写分离中间件

image.png

采用CQRS架构后的系统分层架构图如下,其中Process模块可以理解为系统的网关,负责内外部系统的消息交互,包括回调以及内部系统的消息自发自收。

image.png

引入CQRS架构后的工程规范如下:


image.png

新的系统工程结构如下


用户侧

医生&管理侧

医生ID生成模型

用户侧通过订单生成id的后10bit绑定用户的后10bit,可以保证用户id和订单id两个中任何一个字段作为分库分表字段都能精确查询到数据,而不用全库表扫描。具体可以参考我写的分布式主键ID生成算法
用户下单时可以指定具体医院具体科室的某个医生,也可以不指定具体医生,只指定满足部分条件。我们整理了一下相关条件,整理出下面4个大类:

  • 渠道。这里的渠道包括渠道和子渠道(子渠道可以理解为端),渠道的定义见上面的歧义概念说明。
  • 医院。医院是分布在具体省市下面的医院。
  • 科室。
  • 职称。
    用户不指定具体医生的订单对应到抢单场景,哪些医生可以去抢哪些订单?我们可以这么理解用户下不指定具体医生订单:用户下的是满足某些条件的那批医生共有的医生账号(这个是一个虚拟的账号,可以理解为共有的门禁卡)。
    微医生组接入的医生有一个ID,这个ID是跟身份证是一一对应的,但是一个医生可以通过承接指定渠道的订单,医生也可以以不同身份在不同医院,或者以不同的科室去接不同的订单。所以需要问诊场景下的医生ID来控制接单。根据医生ID进行分库分表,需要一个支持所有类型订单的医生ID模型,需要一个支持派单和抢单场景下的医生ID模型
    ID生成模型
    image.png

1位冗余位:【当其他位不够得时候扩展该位】
8位来设置【渠道】:2^8=256;【例如:主站,互联网医院、微医通】
8位来设置【端】:2^8=256;【例如:友邦,h5,app】
6位来设置【省】:2^6=64;【中国有34个省级行政区 其中,有23个省、5个自治区、4个直辖市、2个特别行政区】
5位来设置【市】:2^5=32;【地级市最多的省份是广东:21个】
12位来设置【医院】:2^12=4096;【标准医院对应】【支持自定义】
10位来设置【科室】:2^10=1024;【标准科室对应】【支持自定义】
4位来设置【职称】:2^4=16;【主任医师、副主任医师、主治医师、住院医师、主任中医师、副主任中医师、主治中医师、***】
10位来设置【医生】:2^10=1024个医生;
【注:上述全部是1的时候是默认保留值,所以上述实际数量需要减一】
模型解释举例
支持用户不指定或者部分指定条件(渠道、医院、科室、级别,其中渠道是不透出给用户选择)下单,以全科订单为例。
患者下单: 1 000000001 00000001 111111 11111 111111111111 111111111 11111 1111111111【几乎全部为默认,因为科室需要根据主诉匹配出来】
转化后【可被刷到的id】: 1 000000001 00000001 111111 11111 111111111111 0000000001 1111 1111111111【医生符合这个科室的都可以抢单】
微医的全科医生的个人账号为 1 000000001 00000001 111111 11111 111111111111 0000000001 0001 000000011,该医生对应的16个虚拟医生id(满足某些条件医生共有的id,这16个ID在同一个分表下面)如下:

image.png

一个医生通过他自己个人账号查询用户指定他的订单。同时这个医生也可以去抢单,这个医生能抢的订单是满足某个或某几个的条件的16个共用账号下的订单。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,335评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,895评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,766评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,918评论 1 285
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,042评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,169评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,219评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,976评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,393评论 1 304
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,711评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,876评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,562评论 4 336
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,193评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,903评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,142评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,699评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,764评论 2 351

推荐阅读更多精彩内容

  • Domain-Driven Design 领域模型对所有软件从业者来讲都不是一个陌生的名词,一个软件产品的内在质量...
    彦帧阅读 1,446评论 0 4
  • 关于Mongodb的全面总结 MongoDB的内部构造《MongoDB The Definitive Guide》...
    中v中阅读 31,916评论 2 89
  • 曾经是路人相过,如今也是敬佩的人物。 先讲讲路人的相过,微博关注了虾米音乐,虾米应该跟他有合作,推广他的新专辑《无...
    Xfor阿妤阅读 211评论 0 1
  • 一旦深爱过一个人, 就会成为她一部分的身影, 看她笑, 陪她哭。 泪痕里难以磨灭伤人的过去, 当所有的承诺与誓言都...
    筋工元素阅读 158评论 0 2
  • 天热了,窗外的蝉儿像磨牙似的燥起来,声音此起彼伏,像是一群和尚头在不停的念经一般,课室里老师一手抱着课本和麦...
    曹麟子阅读 148评论 0 0