需求整理
背景
问诊平台可以看作是电商场景下的交易平台，患者是买家，医生是卖家，医生的排班可以看作是库存，医患沟通可以看作是物流。
问诊平台的愿景是打造线上“一站式诊疗服务”，实现线上就诊场景的闭环。
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个共用账号下的订单。
网友评论