產品架構設計之產品實體設計一,二

0 評論 1758 瀏覽 7 收藏 12 分鐘

本文深入探討了實體設計的每個關鍵步驟,從識別核心實體到定義其屬性、構建實體間關系,以及如何驗證設計以適應實際業務需求。通過具體的電商平臺案例,我們展示了如何將抽象的業務概念轉化為具體的產品架構,確保設計既符合當前需求又具備未來擴展的可能。

今天我們來談一下產品架構設計中,一個必不可少的環節——實體設計。

01什么是實體?

在產品架構中,實體可以理解為“名詞”——即產品中的關鍵要素或對象。這些實體是產品功能的基本構件,代表了實際業務中的具體事物或概念。

比如,在一個電商平臺中,用戶、商品、訂單都是典型的實體。它們是產品中不可或缺的部分,是我們要處理和操作的對象。

那我們為什么要抽象設計實體?

抽象設計實體的目的是為了把復雜的業務場景和需求轉化為易于理解和實現的模型。實體是產品中最基本的組成單元,通過抽象設計實體,我們能夠:

  • 明確產品的核心功能:將實際業務中的復雜對象抽象為實體,可以清晰地看到產品的核心功能和組成部分。
  • 簡化系統設計:實體的抽象設計能夠幫助我們將復雜的邏輯拆解成可管理的部分,使系統設計更加簡潔、易于維護。
  • 提高可擴展性:通過合理的實體設計,可以使產品架構具有良好的擴展性,方便未來的功能擴展和更新。

而如果用大白話來解釋就是:我們將一個模糊的業務,提煉出真正要“落庫”的數據表,畢竟計算機只能處理結構化的數據!

那可能有朋友要問了在產品架構中為什么要先設計實體?

實體設計是產品架構設計的基礎。實體設計決定了產品的基本結構和邏輯,是后續流程設計、數據模型設計、界面設計等工作的基礎。

如果沒有一個清晰的實體設計,整個產品架構將會缺乏堅實的基礎,導致功能實現的復雜度增加,系統難以擴展和維護。

試想下如果大家連頁面上放什么字段都沒有想清楚,一上來就畫頁面,這樣的產品在大型的企業級B端產品中是不敢想象的災難設計。

所以說在產品架構設計中,實體設計是將業務需求轉化為技術實現的橋梁。一個優秀的實體設計不僅能夠支撐產品的現有功能,還能為未來的擴展奠定堅實的基礎。

02 實體設計的方法

具體來說,我們設計實體的方法可以分為下面的4步:

1. 識別關鍵實體

在產品架構設計初期,首先要識別出產品中的關鍵實體。在絕大多數的時候,這些實體通常對應于產品中的核心功能或流程,代表了業務中的主要對象(比如會員,訂單,商品等)。

步驟:

  1. 分析線下用戶的工作場景,提取出與用戶交互最頻繁的關鍵詞對象。
  2. 從業務流程中找出對產品功能至關重要的元素。

例如:梳理用戶報銷場景:用戶提供票據,填寫金額,提交紙質表單,領導簽字該表單,財務查閱該表單……..(這張表單就是我們要提煉的實體-報銷單)

2. 定義實體屬性

因為每個實體都有其獨特的屬性,而在找到實體后就需要提煉實體的屬性,這些屬性描述了實體的特征和狀態。

步驟:

  1. 列出每個實體能唯一區分的屬性,如ID、名稱、描述等。
  2. 根據業務需求,增加與業務邏輯相關的屬性。

例如:報銷單中唯一能區分的屬性是單據號,單據類型,而根據A公司要求,單據中必須要有申請人ID,申請人職位,申請人職級……(這些唯一項與A公司的要求共同構成了實體屬性字段)

3. 設計實體之間的關系

實體之間的關系是產品邏輯的核心。通過設計實體間的關系,可以確定系統的邏輯結構和數據流動。

步驟:

  1. 確定實體之間的關聯類型,如一對一、一對多、多對多等。
  2. 使用實體關系圖(ER圖)來展示實體之間的關系。

4. 驗證實體設計

設計完成后,需要對實體設計進行驗證,以確保其能夠滿足業務需求,并具備良好的擴展性和可維護性。

步驟:

  1. 使用實際業務場景進行測試,驗證設計的合理性。
  2. 通過模擬操作流程,檢查設計的健壯性和容錯性。

例如我們將抽象出的報銷單據實體,在整個線下流程中進行實測,檢測有無缺少的字段,有無流程跑不通的情況,就像財務是不是拿到這張單據就可以不要領導簽字,在實際與財務溝通后由于公司性質要求,所以必須要簽字,因此報銷單的實體中還需要增加標識屬性,是否已打印出待簽字單,用于區分是否完成了打印動作。

03 模擬案例演示:電商平臺的實體設計

假設我們正在設計一個電商平臺,該平臺的核心功能是讓用戶能夠瀏覽商品、加入購物車、下單購買商品,以及查看訂單狀態。為了實現這些功能,我們需要先設計好平臺中的核心實體。以下是具體步驟及結果輸出,展示如何一步步提煉出實體。

步驟一:識別關鍵實體

在設計實體之前,我們需要了解平臺的主要功能和業務流程:

  1. 用戶瀏覽商品: 用戶可以瀏覽和搜索平臺上的商品。
  2. 加入購物車: 用戶可以將商品加入購物車,準備購買。
  3. 生成訂單并支付: 用戶在購物車中選擇商品后,可以生成訂單并完成支付。
  4. 查看訂單狀態: 用戶可以在訂單歷史中查看已購買商品的狀態和詳情。

基于這些功能需求,我們識別出以下關鍵實體:

  • 用戶(User): 平臺的使用者。
  • 商品(Product): 在平臺上出售的商品。
  • 購物車(Cart): 用戶選擇并準備購買的商品集合。
  • 訂單(Order): 用戶生成的購買記錄。

步驟二:定義實體屬性

確定了關鍵實體后,我們需要為每個實體定義屬性,這些屬性將幫助我們詳細描述實體的特征和狀態。

1)用戶(User):

  • 用戶ID(userID): 唯一標識一個用戶的ID。
  • 用戶名(username): 用戶的名稱。
  • 郵箱(email): 用戶的郵箱地址,用于登錄和聯系。
  • 密碼(password): 用戶的賬戶密碼。
  • 注冊日期(registrationDate): 用戶注冊平臺的日期。

2)商品(Product):

  • 商品ID(productID): 唯一標識一個商品的ID。
  • 商品名稱(productName): 商品的名稱。
  • 描述(description): 商品的詳細信息。
  • 價格(price): 商品的售價。
  • 庫存數量(stockQuantity): 當前商品的庫存數量。
  • 創建日期(createdDate): 商品上架的日期。

3)購物車(Cart):

  • 購物車ID(cartID): 唯一標識一個購物車的ID。
  • 用戶ID(userID): 關聯到用戶的購物車。
  • 商品列表(products): 當前購物車中所有商品的集合。

4)訂單(Order):

  • 訂單ID(orderID): 唯一標識一個訂單的ID。
  • 用戶ID(userID): 生成訂單的用戶ID。
  • 訂單日期(orderDate): 訂單生成的日期。
  • 訂單狀態(orderStatus): 訂單的當前狀態(如待付款、已付款、已發貨、已完成)。
  • 商品列表(products): 訂單中包含的商品列表。
  • 總金額(totalAmount): 訂單中所有商品的總金額。

步驟三:設計實體之間的關系

在定義了實體和它們的屬性之后,接下來是設計實體之間的關系。這些關系將決定平臺的邏輯結構。

  • 用戶與購物車(User-Cart):一個用戶只有一個購物車(1:1 關系)。
  • 用戶與訂單(User-Order):一個用戶可以有多個訂單(1:多 關系)。
  • 購物車與商品(Cart-Product):一個購物車可以包含多個商品,一個商品可以出現在多個購物車中(多:多 關系)。
  • 訂單與商品(Order-Product):一個訂單可以包含多個商品,一個商品可以出現在多個訂單中(多:多 關系)。

步驟四:驗證實體設計

最后,我們通過模擬一些實際場景來驗證實體設計的合理性和完整性。

1)用戶瀏覽并加入商品到購物車:

  • 用戶登錄(User),瀏覽商品(Product),將商品加入購物車(Cart)。
  • 檢查購物車中是否正確記錄了所選商品。

2)用戶生成訂單并支付:

  • 用戶從購物車中選擇商品生成訂單(Order),并進行支付。
  • 驗證訂單中包含的商品列表和總金額是否正確計算。
  • 檢查訂單狀態是否從“待付款”變為“已付款”。

3)用戶查看訂單狀態:

用戶可以在訂單歷史中查看已生成的訂單及其狀態(OrderStatus)。

以上為大家演示的就是一個完整的實體找尋與定義的流程。

04 總結

可以看到這樣的設計背后,我們一步步的把抽象的業務具體化得到了標準的可產品化的設計,而這也是高階產品所必備的技能。

本文由人人都是產品經理作者【三爺茶館】,微信公眾號:【三爺茶館】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于 CC0 協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!