一,业务现状分析和诊断
1.1 服务繁多维护麻烦
目前每个地市级部署Center+App,Vehicle,报表，病历等各个服务 11个服务左右，不仅对服务器资源要求比较高，而且运维也是一个问题，出现问题又需要远程各个地市级进行排查
1.2 服务更新麻烦
如果有什么bug 和需求，而且影响业务bug，各个地区都要更新，导致更新工作量*N
1.3 系统对接麻烦
各地市如果需要对接数据 那个地区需要对接功能都要更新上线，导致频繁更新服务
二，系统技术解决方案
2.1 对内服务保持现有业务逻辑和相应的服务
坐席服务和基础服务 各地市业务场景有差异，保持现有的业务逻辑不变
2.2 分化系统以领域驱动设计
每个功能都是独立的个体,业务功能就如组件一样 可以是服务的一部分，也可以随时剥离服务
2.3 保持当前业务正常 逐步抽离
当前业务耦合太深，一下子全部剥离出来，不仅bug百出，而且拉长开发周期，先从小的开发慢慢剥离，比如短信功能，我们可以剥离出 短信服务功能到saas平台上去，现在各地市都存在开通或者不开通短信服务功能，短信服务又区分 发送短信和回访短信能功能模块，要么现在用配置项是否开通，现在我们把单独的短信功能开完完成之后 集成到各地市里面，这个短信功能需要那些是saas 平台来控制的，需要开启那些功能只需要点击开启按钮即刻
2.4现在能够独立剥离的业务有那些
1,短信业务
2,监护仪解析功能
3,心电图解析发送功能(需要和纳龙沟通心电服务是否支持)
4,app版本控制功能
5,车载解析功能
6,第三方车载接受工单系统
7,省质控系统
2.5 目前剥离系统所面临什么问题
1,服务交互耦合性太深,剥离系统堪比从新开发系统
2,当前的数据交互方式不准许，只能把独立的数据建立独立的数据库，需要交互的通过api进行交互
3,个性化需求太多，配置项太多，对公用的saas 平台，在大需求上我们可以订阅开通和不开通，在小功能上大家要保持一致性
