3. PMIS平台总体架构设计
PMIS（工程项目管理平台）的总体架构设计不是把功能罗列成一张大图，而是要把“业务怎么运转、应用怎么承载、数据怎么沉淀、技术怎么支撑、系统怎么集成”这五条主线对齐到同一套目标上。架构设计的目标是让平台在项目全生命周期内可扩展、可集成、可治理，而不是一次性堆功能。下面按业务架构、应用架构、数据架构、技术架构、集成架构和评审要点逐层展开，并给出可落地的设计方法与示例参数。
一、业务架构：先定义价值流与业务能力
业务架构回答“平台为谁、支撑哪些业务、按什么流程运转”。工程企业的主价值链通常包括：市场经营→项目立项→策划与设计→采购与分包→施工与进度→质量安全→成本与资金→竣工与运维。业务架构要把这些环节拆成业务能力，再映射到组织与角色。例如“进度管理能力”可细分为：WBS分解、计划编制、进度填报、偏差分析、预警与纠偏。每个能力要明确输入、输出、责任角色和关键指标。
实际做法是建立“业务能力地图 + 价值流”两层结构。能力地图按层级编号，如 L1 项目管理、L2 进度管理、L3 计划编制；价值流则描述从“项目中标”到“项目关闭”的端到端流转。示例：某市政工程企业将业务能力划分为 6 个 L1 域、28 个 L2 能力、96 个 L3 能力，其中“成本管理”域下设置预算、合同、变更、结算、支付 5 个 L2 能力。业务架构的产出应是一份可评审的能力清单，而不是流程图堆叠。
二、应用架构：从能力到可部署的应用模块
应用架构把业务能力转化为可开发、可部署、可复用的应用模块。推荐采用“领域驱动 + 分层”思路：将平台划分为若干业务域（如项目域、合同域、物资域、质量安全域、成本资金域、协同办公域），每个域内再分聚合根与限界上下文。应用模块之间通过明确定义的接口交互，避免跨域直接读写数据库。
应用架构设计要明确三类组件：业务应用（如进度管理、合同管理）、公共支撑（如工作流引擎、消息中心、权限中心、报表引擎）、门户与移动端（统一入口、待办、消息、看板）。示例：进度管理应用对外暴露“计划创建、任务分解、进度上报、偏差查询”四个 API；合同管理应用暴露“合同登记、变更申请、支付申请、结算查询”四个 API。应用之间通过 API 网关调用，禁止跨库直连。
三、数据架构：主数据、事务数据与分析数据分层
数据架构决定平台能否“数出一孔”。建议分为三层：主数据层（组织、人员、项目、供应商、物料、科目）、事务数据层（合同、进度、质量、安全、成本、支付等业务记录）、分析数据层（指标、报表、看板、数据仓库）。主数据必须统一编码，例如项目编码采用“区域码+年份+序列号”，如 HD-2024-0017；物料编码采用“大类+中类+小类+流水”，如 M-03-02-00045。
数据架构还要定义数据责任：谁产生、谁维护、谁使用。示例：项目主数据由项目管理部维护，供应商主数据由采购部维护，科目主数据由财务部维护。事务数据按“谁业务谁负责”原则落库，分析数据由数据平台统一抽取。数据质量规则要可执行，例如“合同金额必须大于 0”“进度填报日期不得晚于当前日期”“支付累计不得超过合同金额的 90%”。
四、技术架构：支撑高可用与可扩展
技术架构回答“用什么技术、怎么部署、怎么保障”。典型分层为：基础设施层（云/机房、网络、存储）、平台服务层（容器、微服务、网关、注册配置、消息队列、缓存）、数据层（关系库、缓存、对象存储、搜索引擎）、应用层（前端、后端服务）、安全与运维层（认证、审计、监控、日志、备份）。
示例参数：采用 Kubernetes 部署，核心服务副本数≥2；MySQL 主从 + 读写分离；Redis 缓存会话与热点数据；Kafka 处理异步消息；对象存储保存图纸与附件；Prometheus + Grafana 监控，日志集中到 ELK。技术架构要明确非功能指标：可用性≥99.9%，关键接口响应≤500ms，支持 5000 并发用户，数据备份 RPO≤15 分钟、RTO≤2 小时。
五、集成架构：与外部系统的连接方式
集成架构解决 PMIS 与财务、OA、BIM、HR、采购、税务等系统的数据交换。推荐“API 优先 + 消息补充 + 文件兜底”三种方式：实时查询走 REST API；状态变更走消息队列；批量对账走文件导入导出。集成要定义接口契约：接口名、方向、频率、字段、错误码、重试策略。
示例：PMIS 与财务系统集成“支付申请”接口，PMIS 推送支付单号、合同号、金额、收款方、审批状态；财务返回凭证号与支付状态。频率为实时，失败重试 3 次，间隔 30 秒，仍失败则进入人工处理队列。集成架构还要考虑幂等性：同一支付单号重复推送不得重复入账。
六、架构评审要点：把设计变成可检查的清单
架构评审不是“看图说话”，而是逐项验证设计是否可落地。建议从六个维度评审：业务覆盖（能力清单是否覆盖全生命周期，有无遗漏）、应用边界（模块职责是否单一，是否存在跨域直连）、数据责任（主数据是否有唯一来源，质量规则是否可执行）、技术指标（可用性、性能、容量、备份是否量化）、集成契约（接口是否有字段、频率、错误码、重试与幂等定义）、演进路径（是否支持分期上线与灰度扩展）。
评审时要带具体证据：例如“进度管理应用是否只通过 API 访问合同数据”“项目主数据是否由项目管理部唯一维护”“支付接口是否定义幂等键”。评审结论应分为通过、有条件通过、不通过三档，并明确整改责任人与期限。示例评审表字段：评审项、评审要点、证据材料、结论、整改要求、责任人、完成时间。只有把架构设计转化为可检查、可整改的条目，PMIS 总体架构才能真正指导后续开发与集成。