在產(chǎn)品開發(fā)中，我們常常會(huì)忽略一個(gè)重要的原則：“模型應(yīng)該更具抽象概念，不應(yīng)該賦予業(yè)務(wù)屬性。”簡(jiǎn)單的一句話，值得我們深思。本文作者分享了他對(duì)這句話的理解和思考，大家可以參考。

昨天在項(xiàng)目群里討論問題時(shí)，有個(gè)同事提到一個(gè)觀點(diǎn)讓我印象深刻：“模型應(yīng)該更具抽象概念，不應(yīng)該賦予業(yè)務(wù)屬性。”簡(jiǎn)單的一句話，卻揭示了一個(gè)我們?cè)陂_發(fā)中經(jīng)常忽略的重要原則。

今天就來聊聊這句話背后的深意，以及它為什么值得我們?cè)谀Ｐ驮O(shè)計(jì)中深刻反思。

01 什么是模型的“抽象概念”？

在軟件開發(fā)中，模型是現(xiàn)實(shí)世界在系統(tǒng)中的抽象表達(dá)。比如，“用戶”這個(gè)模型在最抽象的層面上，可以定義為：

• 用戶名
• 密碼
• 郵箱
• 唯一標(biāo)識(shí)（ID）

這些屬性是用戶的本質(zhì)，而與具體的業(yè)務(wù)無關(guān)。與之相對(duì)的是業(yè)務(wù)屬性，比如：

• 用戶下了多少訂單。
• 用戶的會(huì)員等級(jí)。
• 用戶是否參與了某次活動(dòng)。

這些是與業(yè)務(wù)相關(guān)的邏輯，不屬于用戶的本質(zhì)。模型的抽象性，就是專注于本質(zhì)屬性，而不是具體業(yè)務(wù)場(chǎng)景中那些容易變動(dòng)的部分。

02 為什么模型設(shè)計(jì)要“去業(yè)務(wù)化”？

在項(xiàng)目開發(fā)中，把模型設(shè)計(jì)得過于貼合具體的業(yè)務(wù)場(chǎng)景，很容易埋下隱患。以下是幾個(gè)關(guān)鍵原因：

1. 降低系統(tǒng)耦合，保持靈活性

業(yè)務(wù)邏輯是動(dòng)態(tài)的、經(jīng)常變化的。如果模型被綁定到具體業(yè)務(wù)屬性上，那么每次業(yè)務(wù)調(diào)整時(shí)，模型都可能需要修改，導(dǎo)致系統(tǒng)的其他部分被連帶影響。

舉個(gè)例子：

如果“用戶模型”包含“訂單數(shù)量”字段，那么訂單系統(tǒng)的改動(dòng)會(huì)直接影響用戶模型，甚至需要改動(dòng)數(shù)據(jù)庫結(jié)構(gòu)。

這樣的耦合讓系統(tǒng)變得非常脆弱。而抽象模型通過專注本質(zhì)，減少了這種相互牽絆的風(fēng)險(xiǎn)。

2. 提高模型復(fù)用性

一個(gè)好的抽象模型，可以在不同的業(yè)務(wù)場(chǎng)景中被復(fù)用。比如，一個(gè)抽象的“用戶”模型，可以應(yīng)用于：

• 電商系統(tǒng)：用于下單和訂單管理。
• 社交平臺(tái)：用于關(guān)系網(wǎng)絡(luò)和用戶動(dòng)態(tài)。
• 企業(yè)內(nèi)部系統(tǒng)：用于人力資源管理。

如果模型里包含了業(yè)務(wù)屬性，比如“購物車內(nèi)容”或“朋友圈動(dòng)態(tài)”，那么它就很難跨越場(chǎng)景復(fù)用，導(dǎo)致代碼和邏輯的重復(fù)。

3. 支持業(yè)務(wù)演進(jìn)

在一個(gè)快速變化的業(yè)務(wù)環(huán)境中，需求的變化往往比我們預(yù)期得更頻繁。如果模型綁定了過多的業(yè)務(wù)屬性，每次需求調(diào)整都會(huì)牽一發(fā)而動(dòng)全身。

相比之下，抽象模型更像是一塊穩(wěn)定的基石，業(yè)務(wù)邏輯可以圍繞它自由演變，而不會(huì)對(duì)核心結(jié)構(gòu)造成過多干擾。

03 如何在實(shí)踐中實(shí)現(xiàn)抽象模型設(shè)計(jì)？

知道了抽象模型的優(yōu)勢(shì)，那該如何在實(shí)際開發(fā)中實(shí)現(xiàn)呢？以下是一些可操作的設(shè)計(jì)方法：

1. 專注對(duì)象的本質(zhì)

設(shè)計(jì)模型時(shí)，盡量只保留那些反映對(duì)象本質(zhì)的屬性。例如：

用戶模型只包含“用戶名”、“郵箱”等基本信息，而不是“是否參與某活動(dòng)”這樣的業(yè)務(wù)字段。

這樣的設(shè)計(jì)可以保證模型的穩(wěn)定性，避免被業(yè)務(wù)需求牽著走。

2. 業(yè)務(wù)邏輯外移

將復(fù)雜的業(yè)務(wù)邏輯從模型中移到服務(wù)層或領(lǐng)域?qū)ο笾?。比如?/p>

“用戶的訂單統(tǒng)計(jì)”應(yīng)該由訂單服務(wù)來負(fù)責(zé)，而不是直接嵌入用戶模型。

通過分層設(shè)計(jì)，我們可以將模型和業(yè)務(wù)邏輯解耦，確保模型的純凈。

3. 使用組合代替繼承

當(dāng)需要擴(kuò)展模型功能時(shí)，優(yōu)先使用組合，而不是直接在模型中添加字段。例如：

用一個(gè)單獨(dú)的“會(huì)員信息”模塊，來擴(kuò)展用戶的會(huì)員功能，而不是直接在用戶模型中添加“會(huì)員等級(jí)”。

4. 借助接口與領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

通過定義接口或領(lǐng)域?qū)ο螅苊饽Ｐ驮O(shè)計(jì)受限于具體實(shí)現(xiàn)。例如：

class User:

def __init__(self, user_id, username):

self.user_id = user_id

self.username = username

class MembershipDetails:

def __init__(self, level, expiry_date):

self.level = level

self.expiry_date = expiry_date

這樣可以靈活地?cái)U(kuò)展用戶模型的功能，而不會(huì)破壞其核心結(jié)構(gòu)。

04 典型誤區(qū)與應(yīng)對(duì)策略

盡管“模型抽象化”的理念很好，但在實(shí)踐中我們可能會(huì)遇到以下問題：

1. 過度抽象

如果抽象過度，模型可能變得過于籠統(tǒng)，反而無法滿足實(shí)際需求。例如，將所有業(yè)務(wù)都抽象為“實(shí)體”或“資源”，最后反而失去了模型的意義。

應(yīng)對(duì)策略： 抽象時(shí)，關(guān)注對(duì)象的本質(zhì)屬性，適度平衡抽象與現(xiàn)實(shí)需求。

2. 忽略業(yè)務(wù)的特殊性

有時(shí)，開發(fā)者為了保持模型的抽象性，完全忽略了業(yè)務(wù)需求的復(fù)雜性，導(dǎo)致實(shí)現(xiàn)過程反而更加繁瑣。

應(yīng)對(duì)策略： 結(jié)合領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD），通過分層架構(gòu)，讓模型抽象與業(yè)務(wù)邏輯合理分工。

05 抽象模型是穩(wěn)定的，業(yè)務(wù)邏輯是可變的

正如那位同事說的，模型設(shè)計(jì)應(yīng)該專注于抽象概念，而不是被業(yè)務(wù)屬性束縛。這是一個(gè)技術(shù)原則，也是一種長(zhǎng)遠(yuǎn)的系統(tǒng)設(shè)計(jì)哲學(xué)。抽象模型就像穩(wěn)定的地基，支持著不斷變化的業(yè)務(wù)需求。

在未來的開發(fā)中，不妨多花一些時(shí)間，思考你的模型是否過于依賴業(yè)務(wù)屬性？是否可以更抽象、更獨(dú)立？相信這些思考會(huì)讓你的系統(tǒng)更穩(wěn)健，更靈活。

模型是穩(wěn)定的，業(yè)務(wù)是靈活的。把握這兩者的界限，是一個(gè)開發(fā)者真正成熟的標(biāo)志。