為保障車間業(yè)務系統(tǒng)的穩(wěn)定性、可維護性與團隊協(xié)作效率，特制定此基礎軟件服務命名規(guī)范。本規(guī)范適用于所有服務于車間制造執(zhí)行、設備管理、質(zhì)量管理、物料追溯等核心業(yè)務場景的基礎軟件服務（如微服務、后臺服務、數(shù)據(jù)庫、消息隊列等）。
一、 核心原則
- 清晰性：名稱應能準確反映服務的核心功能與業(yè)務領域。
- 一致性：遵循統(tǒng)一的命名模式，便于識別和管理。
- 簡潔性：在表達清晰的前提下，力求簡短，避免過長或過于復雜的詞匯。
- 可讀性：采用有意義的英文單詞或公認縮寫，便于開發(fā)與運維人員理解。
二、 命名結構
基礎軟件服務的完整名稱建議采用多段式結構，以清晰界定其所屬范圍與職責。通用格式如下：
[系統(tǒng)/領域前綴]-[業(yè)務模塊]-[功能描述]-[服務類型]
- 系統(tǒng)/領域前綴 (System/Domain Prefix)：標識服務所屬的頂層系統(tǒng)或領域。對于車間業(yè)務系統(tǒng)，固定使用
shopfloor作為前綴。 - 業(yè)務模塊 (Business Module)：指明服務對應的具體業(yè)務模塊。例如：
mes(制造執(zhí)行系統(tǒng))
equip或device(設備管理)
quality(質(zhì)量管理)
material或wip(物料/在制品管理)
trace(追溯管理)
report(報表服務)
auth(認證授權)
- 功能描述 (Function Description)：用1-2個關鍵詞簡要描述服務的核心功能。例如：
order(工單),status(狀態(tài)),collect(采集),alert(告警),query(查詢),calc(計算)。 - 服務類型 (Service Type)：標識服務的具體技術類型。例如：
svc或service(應用服務/微服務)
api(API網(wǎng)關或核心接口服務)
job或task(定時任務/作業(yè)服務)
mq(消息隊列服務，可結合具體中間件如rabbitmq,kafka)
db(數(shù)據(jù)庫服務，可結合具體數(shù)據(jù)庫如mysql,pg)
cache(緩存服務，如redis)
三、 命名示例
- 制造執(zhí)行-工單服務：
shopfloor-mes-order-svc - 設備管理-狀態(tài)采集服務：
shopfloor-equip-status-collect-svc - 質(zhì)量管理-缺陷告警任務：
shopfloor-quality-defect-alert-job - 物料追溯-查詢API服務：
shopfloor-trace-query-api - 公共認證服務：
shopfloor-auth-svc(業(yè)務模塊為auth時，功能描述可省略) - 車間報表數(shù)據(jù)庫：
shopfloor-report-db - 設備事件消息隊列：
shopfloor-equip-event-kafka
四、 部署與配置關聯(lián)命名
在容器化或虛擬機部署環(huán)境中，建議服務的主機名、容器名、配置文件名稱與上述服務核心名稱保持一致或高度關聯(lián)，以降低運維復雜度。例如，服務 shopfloor-mes-order-svc 對應的Docker容器可命名為 shopfloor-mes-order-svc-container，其配置文件可為 application-shopfloor-mes-order-svc.yml。
五、 版本管理
服務本身的版本號建議通過標簽(Tag)或在其配置中心進行管理，不直接體現(xiàn)在服務的基礎命名中，以保持名稱的穩(wěn)定性。
六、 例外與評審
對于特殊情況或新引入的技術組件，若無法完全適用本規(guī)范，需提交至系統(tǒng)架構委員會或技術負責人進行評審，確定命名方案并酌情更新本規(guī)范。
遵循此規(guī)范，將有助于構建一個條理清晰、易于理解和運維的車間數(shù)字化軟件服務生態(tài)，為智能制造的高效運行奠定堅實的技術管理基礎。
