为保障车间业务系统的稳定性、可维护性与团队协作效率，特制定此基础软件服务命名规范。本规范适用于所有服务于车间制造执行、设备管理、质量管理、物料追溯等核心业务场景的基础软件服务（如微服务、后台服务、数据库、消息队列等）。
一、 核心原则
- 清晰性：名称应能准确反映服务的核心功能与业务领域。
- 一致性：遵循统一的命名模式，便于识别和管理。
- 简洁性：在表达清晰的前提下，力求简短，避免过长或过于复杂的词汇。
- 可读性：采用有意义的英文单词或公认缩写，便于开发与运维人员理解。
二、 命名结构
基础软件服务的完整名称建议采用多段式结构，以清晰界定其所属范围与职责。通用格式如下：
[系统/领域前缀]-[业务模块]-[功能描述]-[服务类型]
- 系统/领域前缀 (System/Domain Prefix)：标识服务所属的顶层系统或领域。对于车间业务系统，固定使用
shopfloor作为前缀。 - 业务模块 (Business Module)：指明服务对应的具体业务模块。例如：
mes(制造执行系统)
equip或device(设备管理)
quality(质量管理)
material或wip(物料/在制品管理)
trace(追溯管理)
report(报表服务)
auth(认证授权)
- 功能描述 (Function Description)：用1-2个关键词简要描述服务的核心功能。例如：
order(工单),status(状态),collect(采集),alert(告警),query(查询),calc(计算)。 - 服务类型 (Service Type)：标识服务的具体技术类型。例如：
svc或service(应用服务/微服务)
api(API网关或核心接口服务)
job或task(定时任务/作业服务)
mq(消息队列服务，可结合具体中间件如rabbitmq,kafka)
db(数据库服务，可结合具体数据库如mysql,pg)
cache(缓存服务，如redis)
三、 命名示例
- 制造执行-工单服务：
shopfloor-mes-order-svc - 设备管理-状态采集服务：
shopfloor-equip-status-collect-svc - 质量管理-缺陷告警任务：
shopfloor-quality-defect-alert-job - 物料追溯-查询API服务：
shopfloor-trace-query-api - 公共认证服务：
shopfloor-auth-svc(业务模块为auth时，功能描述可省略) - 车间报表数据库：
shopfloor-report-db - 设备事件消息队列：
shopfloor-equip-event-kafka
四、 部署与配置关联命名
在容器化或虚拟机部署环境中，建议服务的主机名、容器名、配置文件名称与上述服务核心名称保持一致或高度关联，以降低运维复杂度。例如，服务 shopfloor-mes-order-svc 对应的Docker容器可命名为 shopfloor-mes-order-svc-container，其配置文件可为 application-shopfloor-mes-order-svc.yml。
五、 版本管理
服务本身的版本号建议通过标签(Tag)或在其配置中心进行管理，不直接体现在服务的基础命名中，以保持名称的稳定性。
六、 例外与评审
对于特殊情况或新引入的技术组件，若无法完全适用本规范，需提交至系统架构委员会或技术负责人进行评审，确定命名方案并酌情更新本规范。
遵循此规范，将有助于构建一个条理清晰、易于理解和运维的车间数字化软件服务生态，为智能制造的高效运行奠定坚实的技术管理基础。
