起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識為什么模型應該更具抽象概念，而不是被業務屬性束縛
在產品開發中，我們常常會忽略一個重要的原則：“模型應該更具抽象概念，不應該賦予業務屬性?！焙唵蔚囊痪湓挘档梦覀兩钏?。本文作者分享了他對這句話的理解和思考，大家可以參考。
昨天在項目群里討論問題時，有個同事提到一個觀點讓我印象深刻：“模型應該更具抽象概念，不應該賦予業務屬性。”簡單的一句話，卻揭示了一個我們在開發中經常忽略的重要原則。
今天就來聊聊這句話背后的深意，以及它為什么值得我們在模型設計中深刻反思。
01 什么是模型的“抽象概念”？
在軟件開發中，模型是現實世界在系統中的抽象表達。比如，“用戶”這個模型在最抽象的層面上，可以定義為：
- 用戶名
- 密碼
- 郵箱
- 唯一標識（ID）
這些屬性是用戶的本質，而與具體的業務無關。與之相對的是業務屬性，比如：
- 用戶下了多少訂單。
- 用戶的會員等級。
- 用戶是否參與了某次活動。
這些是與業務相關的邏輯，不屬于用戶的本質。模型的抽象性，就是專注于本質屬性，而不是具體業務場景中那些容易變動的部分。
02 為什么模型設計要“去業務化”？
在項目開發中，把模型設計得過于貼合具體的業務場景，很容易埋下隱患。以下是幾個關鍵原因：
1. 降低系統耦合，保持靈活性
業務邏輯是動態的、經常變化的。如果模型被綁定到具體業務屬性上，那么每次業務調整時，模型都可能需要修改，導致系統的其他部分被連帶影響。
舉個例子：
如果“用戶模型”包含“訂單數量”字段，那么訂單系統的改動會直接影響用戶模型，甚至需要改動數據庫結構。
這樣的耦合讓系統變得非常脆弱。而抽象模型通過專注本質，減少了這種相互牽絆的風險。
2. 提高模型復用性
一個好的抽象模型，可以在不同的業務場景中被復用。比如，一個抽象的“用戶”模型，可以應用于：
- 電商系統：用于下單和訂單管理。
- 社交平臺：用于關系網絡和用戶動態。
- 企業內部系統：用于人力資源管理。
如果模型里包含了業務屬性，比如“購物車內容”或“朋友圈動態”，那么它就很難跨越場景復用，導致代碼和邏輯的重復。
3. 支持業務演進
在一個快速變化的業務環境中，需求的變化往往比我們預期得更頻繁。如果模型綁定了過多的業務屬性，每次需求調整都會牽一發而動全身。
相比之下，抽象模型更像是一塊穩定的基石，業務邏輯可以圍繞它自由演變，而不會對核心結構造成過多干擾。
03 如何在實踐中實現抽象模型設計？
知道了抽象模型的優勢，那該如何在實際開發中實現呢？以下是一些可操作的設計方法：
1. 專注對象的本質
設計模型時，盡量只保留那些反映對象本質的屬性。例如：
用戶模型只包含“用戶名”、“郵箱”等基本信息，而不是“是否參與某活動”這樣的業務字段。
這樣的設計可以保證模型的穩定性，避免被業務需求牽著走。
2. 業務邏輯外移
將復雜的業務邏輯從模型中移到服務層或領域對象中。比如：
“用戶的訂單統計”應該由訂單服務來負責，而不是直接嵌入用戶模型。
通過分層設計，我們可以將模型和業務邏輯解耦，確保模型的純凈。
3. 使用組合代替繼承
當需要擴展模型功能時，優先使用組合，而不是直接在模型中添加字段。例如：
用一個單獨的“會員信息”模塊，來擴展用戶的會員功能，而不是直接在用戶模型中添加“會員等級”。
4. 借助接口與領域驅動設計
通過定義接口或領域對象，避免模型設計受限于具體實現。例如：
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
這樣可以靈活地擴展用戶模型的功能，而不會破壞其核心結構。
04 典型誤區與應對策略
盡管“模型抽象化”的理念很好，但在實踐中我們可能會遇到以下問題：
1. 過度抽象
如果抽象過度，模型可能變得過于籠統，反而無法滿足實際需求。例如，將所有業務都抽象為“實體”或“資源”，最后反而失去了模型的意義。
應對策略： 抽象時，關注對象的本質屬性，適度平衡抽象與現實需求。
2. 忽略業務的特殊性
有時，開發者為了保持模型的抽象性，完全忽略了業務需求的復雜性，導致實現過程反而更加繁瑣。
應對策略： 結合領域驅動設計（DDD），通過分層架構，讓模型抽象與業務邏輯合理分工。
05 抽象模型是穩定的，業務邏輯是可變的
正如那位同事說的，模型設計應該專注于抽象概念，而不是被業務屬性束縛。這是一個技術原則，也是一種長遠的系統設計哲學。抽象模型就像穩定的地基，支持著不斷變化的業務需求。
在未來的開發中，不妨多花一些時間，思考你的模型是否過于依賴業務屬性？是否可以更抽象、更獨立？相信這些思考會讓你的系統更穩健，更靈活。
模型是穩定的，業務是靈活的。把握這兩者的界限，是一個開發者真正成熟的標志。
本文由 @好帥的舅舅 原創發布于人人都是產品經理，未經授權，禁止轉載
題圖來自Unsplash，基于CC0協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
如果是這種通用類型的模型，是不是也說明很容易被AI替代？
所以一個好的技術是多么的重要，產品梳理清業務邏輯，技術根據業務邏輯設計出清晰的數據庫結構；
抽象化的模型減少了系統各部分之間的依賴，使得系統更加靈活，能夠適應業務的變化。