電子商務訂閱 - 應用程序設計困境

Question

我正在設計一個應用程序，提供訂閱會員的優質內容。因此，該應用程序包含電子商務功能，因此用戶可以購買訂閱。以下是迄今爲止的UML靜態圖的草案。

雖然將舉行它看起來像它應該有外鍵訂閱信息的數據庫表中編寫DDL到兩個用戶表和支付表。但是，這似乎違反了一些基本的數據庫設計概念，因爲可以通過訂單表來確定哪個用戶來自哪個用戶。有沒有更好的方法來設計類比圖中列出的，以消除冗餘？

Answer 1

• 你有冗餘，真的很棒，因爲你沒有選擇導航的方向。無箭頭關聯指的是在兩個方向上的關聯。你可以使用它，但不是所有的連接！如果訂單將只有單向導航到付款和用戶，您的問題就會消失。
• 您尚未連接購物車和訂單。通常他們緊密聯繫在一起：（0..1）。或者將訂單設置爲推車的一般化。購物車需要約會？真？但訂單應該有更多信息 - 消息，交付和事情。或訂閱有一些特殊的邏輯？那麼你也沒有在這裏。
• 而不是單詞「包含」使用聚合 - 共享和組合。
• '有'應該由dot/end ownership顯示，而不是用文字。你有他們，誰有誰？
• 'activites'應顯示（如果有的話）作爲依賴關係，除了關聯。
• 我建議做劃分用戶帳戶（僅用於識別/登錄需求）和使用信息（地址和其他東西）。
• 訂單中的項目和項目更接近。使用泛化，而不是'是'。此外，訂購後訂單中的物品被克隆並獲得固定價格。哪裏是？

事實上，圖的邏輯根本不明顯。考慮製作更高層次的圖表。狀態機甚至用例來啓動。