在產(chǎn)品開發(fā)中，我們常常會忽略一個重要的原則：“模型應(yīng)該更具抽象概念，不應(yīng)該賦予業(yè)務(wù)屬性?！焙唵蔚囊痪湓挘档梦覀兩钏?。本文作者分享了他對這句話的理解和思考，大家可以參考。

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

今天就來聊聊這句話背后的深意，以及它為什么值得我們在模型設(shè)計中深刻反思。

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

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

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

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

• 用戶下了多少訂單。
• 用戶的會員等級。
• 用戶是否參與了某次活動。

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

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

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

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

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

舉個例子：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 使用組合代替繼承

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

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

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

通過定義接口或領(lǐng)域?qū)ο?，避免模型設(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

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

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

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

1. 過度抽象

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

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

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

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

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

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

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

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

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