科杰企业级系统（前后端分层与模块边界）

1. 文档定位

本文档用于明确科杰企业级系统在技术实施中的前后端分层方案、模块边界、BFF 角色与权限控制方式，避免后续开发中出现“页面写业务、接口写重复逻辑、权限四处散落”的问题。

2. 总体分层

建议整体采用 5 层结构：

表现层（PC / H5 / 协同门户）
BFF 层（按终端整形接口）
应用服务层（按业务域组织）
领域服务层（核心业务规则）
基础设施层（数据库、缓存、文件、消息、调度）

3. 前端分层建议

3.1 PC 管理端

建议拆成以下层：

layouts：主布局、导航、工作台容器
views：页面视图
components：复用表单、表格、附件上传、状态标签、流程组件
stores：用户、权限、字典、页面状态
services：API 请求封装
utils：权限判断、时间格式、导出下载、文件预览

前端原则

页面不直接拼复杂业务规则；
复杂规则交给后端；
前端负责交互组织、状态展示、表单校验、权限显隐。

3.2 移动端

建议聚焦：

待办
填报
签字
扫码
工单执行
告警查看

移动端也建议分层：

页面层
轻组件层
API 服务层
本地缓存层（少量）

3.3 门户端（后续）

客户门户、维保商门户、供应商门户不建议与内部后台共用一个大前端工程。建议：

独立门户工程
共用统一认证和 API 网关
仅开放授权页面和接口

4. BFF 层建议

4.1 为什么需要 BFF

因为不同端关注点不同：

PC端偏完整管理视图；
移动端偏高频动作与轻量摘要；
外部门户偏只读与受限写入。

所以建议增加 BFF 层，而不是所有终端直接打后台领域接口。

4.2 BFF 的职责

聚合多个领域接口
按终端裁剪字段
做统一页面级权限判断
做菜单、工作台、摘要数据拼装
控制移动端接口简化输出

4.3 BFF 不应承担的职责

不承载核心业务规则
不自行决定状态流转
不替代领域服务做审批
不写复杂事务

5. 后端应用层按域划分建议

建议按以下域组织应用模块：

5.1 auth-domain

登录
Token
用户信息
权限与数据范围

5.2 crm-domain

客户
联系人
商机
报价
合同/订单

5.3 design-domain

机型
电控方案
图纸
PLC版本
BOM模板
工程变更

5.4 equipment-domain

设备主档
一机一档
随机资料
交付资料绑定
生命周期状态

5.5 ledger-domain

日检
月检
维保
年度自检
定检准备
补录
整改闭环

5.6 service-domain

服务工单
派工
服务记录
配件使用
服务反馈

5.7 compliance-domain

检验周期
使用登记状态
合规风险
报检资料导出

5.8 file-domain

附件上传
文件元数据
权限下载
资料包导出

5.9 notification-domain

站内通知
短信/企微/钉钉接口
待办提醒

5.10 analytics-domain

数据快照
看板聚合
指标统计

5.11 iot-domain（一期预留）

联网设备
采集点配置
告警事件
运维记录

6. 领域层设计建议

每个域建议包含：

Entity / Aggregate
Domain Service
Repository Interface
Policy / Rule
Domain Event

例如 ledger-domain 可包含：

InspectionTask
DailyInspection
MonthlyInspection
MaintenanceRecord
AnnualSelfCheck
RectificationTask
LedgerDomainService
LedgerPolicy
LedgerEventPublisher

7. 模块边界建议

7.1 设备主档是中心域

多个模块都围绕设备主档展开，但不允许每个模块自己维护“另一份设备信息”。

统一归属：

设备编码
检验有效期
登记状态
主机型
交付信息

都应由 equipment-domain 持有主权。

7.2 标准设计资产是独立资产域

图纸、PLC、BOM、方案不应散落在生产模块或设备模块中，必须统一由 design-domain 管理，再通过绑定关系引用到设备。

7.3 台账域不直接控制合规结论

台账域负责记录事实与问题，但“最终是否构成合规风险、是否关闭风险”应由 compliance-domain 管理。

7.4 服务域不直接修改设备主档核心状态

服务工单可以回写服务记录和建议，但设备核心状态修改仍应通过设备域或合规域进行。

8. 接口边界建议

8.1 查询型接口

可通过 BFF 聚合输出
优先适配页面需求

8.2 写入型接口

必须直接落到对应领域域服务
不允许跨多个域随意拼事务

8.3 导出型接口

走异步任务
导出任务与文件元数据统一归 file-domain 或 export-domain

9. 权限控制落点建议

权限控制分三层：

9.1 前端层

控菜单
控按钮显隐
控字段只读态

9.2 BFF 层

控页面级数据裁剪
控摘要页字段

9.3 后端领域层

真正做最终鉴权
控写权限
控审批权限
控数据范围

10. 推荐目录结构（后端）

src/main/java/com/kejie/
  auth/
  crm/
  design/
  equipment/
  ledger/
  service/
  compliance/
  file/
  notification/
  analytics/
  iot/
  common/

11. 推荐目录结构（前端）

src/
  layouts/
  router/
  stores/
  api/
  views/
    dashboard/
    crm/
    design/
    equipment/
    ledger/
    service/
    compliance/
    analytics/
    system/
  components/
  utils/

12. 结论

前后端分层的关键不是“看起来先进”，而是要确保：

领域边界清楚；
主数据不重复维护；
页面和业务规则分离；
多端可以稳定扩展；
后续 IoT 和外部协同能接得上。

只要这几点守住，系统就能从一期平滑演进，而不会越做越乱。

科杰企业级系统：前后端分层与模块边界