中心思想：
发现即解决根本（单点），不做临时反复性补丁
解决方案
责任明确划分
增加临时性补丁模块（适配器模式）
增加消息中心
删减重构部分模块
Web端 基于 项目合并或切割及ABP处理结果 进行删减合并性重构
项目增加readme 描述接口使用方 调用节点，方便删减整理 排除无效卡点
查阅整理所有项目代码，做到对各个项目至少有基本业务理解，这是一个排坑的过程，防止之后出现临时问题当场懵逼
1、部署问题
1.1 为什么每次部署都那么难?
是缺少文档性说明，还是缺少自动化工具? 部署过程的参数 是不是不够清晰。1.2 开发环境不稳定
假设生成环境部署成功可以稳定运行，那是什么原因导致开发环境的不稳定？
每次解决都要几分钟至跨天不等，是某些问题反复发生，还是发现不了问题的本质原因？
不能每次都是临时性解决1.3 版本问题
应该从git、docker镜像到系统展示层面有完整一致的版本标识
不能问题解决即发版，一般性问题应该积压发版列表，统一发布1.4 快速还原生产到开发或测试环境
2、肯叟机制问题
2.1 app接口配置 改成 通配（押后）
2.2 这玩意不能再手动处理了 一定要提供工具
比对
发布生成
目标：不再手动重复性创建配置
3、Web结构问题
SystemWeb
PlatformWeb
CompanyWeb
BrokerWeb
是不是有必要整理合并
4、ABP
4.1 转发一切请求
本身是一个前后对接的事，为什么搞成了三方对接4.2 对基础层面的限制
比如 组织机构啥的
5、数据库问题
有没有可能统一只用 pg 或者 sql server
6、统一风格
5.1 UTC
对UTC提出完整性解决方案（前后端），遇到即处理
当前过滤数据因UTC产生的问题有多少 不可预估5.2 KV 传递问题，影响统一封装
统一获取源头
只存K、只存V、还是都存、
模型是 key,value，name,value，id, name
7、消息链路
发送时机、用途不清晰，影响系统的扩展性
建立消息中心做 消息复制分发和数据处理
8、不安全、不确定的模块
租赁二手房 的电子合同 -- 基本没使用过吧
实勘 -- 觉得有些复杂
经纪人 -- 数据结构需要重新考量
统计 -- 有疑问啊 是不是要再重新来过
客源 -- 对于归属 重新设计和明确一下
组织机构 -- 整个拿出来说一下嘛
9、重复性太高
Web的组件封装
Web的重复性代码
kv的重复性接口
组织机构的重复性存储
10、数据的不一致性
数据的出处不一致，导致的数据不一致，比如某处的经纪人列表 和详情
