平台类产品的研发思考
平台类产品需要遵循以下规则：
1、为某种目的而产生，平台类是为来解决某种具体的问题，比如：为了统一开发技术栈、为了屏蔽底层开发模式、为了降低实施开发成本
2、从某方面带来的好处，大于它带来的局限，比如：进行了模块化抽象处理，提升了开发的便捷度，但是降低了其灵活度、扩展度
3、来源于业务，但不局限于业务，平台的产品需要解决具体的业务问题，但是必须向通用化、标准化发展，例如：业务流水号生成规则、开工、报工等业务统一的处理流程
4、必须有其自身存在的合理性，平台始终是一种工具，是对通用业务的典型封装，只要有10个以上的业务项目，其必然会产生平台类需求
平台必须有其自己的合理性，先进性、必要性，否则那便没有存在的意义
5、平台本身相当于一个组织，有其扩展性、扩张性的内生需求，要限定其使用范围、聚焦到具体领域，做精品而不是支持通用需求的四不像（表单+流程满足OA领域与人的快速交互，表单开发支持快速简单应用管理，拖拽式开发支持？）
我们所有的平台都需要对现有的业务具体提供实质性的帮助与效率的提升
优势分析：
1、有图形化的设计前端，便于动态调整
2、有基于graphql的自定义sql查询，便于动态的调整查询方式，缺少直接的sql支持
3、有基于模型驱动的设计理念，完成全项目的开发
4、有基于微服务架构/领域驱动模型的业务模块划分，降低耦合
5、有基于React的前端技术积累，前端技术强大
不足分析：
1、模型驱动的设计开发方式，暂时还不顺手，整体的开发模式还未建立（开发/代码开发，部署上传流程不够简洁）
2、自定义的sql实现模式还不便利（除了graphql，无法支持自定义的查询）
3、图形化的开发方式，在扩展二开方面还缺少细节的提升（缺少指导二次开发的思想）
4、移动端的开发，还处于初级阶段
5、做大而全的平台，还是聚焦/收敛到固定领域，解决具体问题
前景/市场要求
1、降低开发/二次开发难度是大的趋势，也是后续的发展方向
2、从业务模型驱动开发，落地DDD是当前一段时间的主要任务
3、移动端的支持
4、对于中小型项目的快速支持、快速实现、业务组件的快速封装提升
参考项目：
xx能源管理项目，是基于React多代码开发的完整项目，非拖拽式前端开发，自行实现了系统管理基本功能（大多数项目的系统管理都很简单），自行实现了大量的前端组件开发封装，支持websocket等新的功能
生产执行管理系统 基于拖拽开发，后端CQRS -DDD，使用iEEP平台提供的系统管理、技术组件包
