订阅电子商务 - 应用程序设计困境

Question

我正在设计一个为订阅会员提供优质内容的应用程序。因此，该应用程序包含电子商务功能，因此用户可以购买订阅。下面是目前为止的UML静态图的草稿

在为将保存订阅信息的数据库表编写DDL时，似乎它应该具有Users表和Payments表的外键。但是，这似乎违反了一些基本的数据库设计概念，因为通过Orders表可以确定哪个支付来自哪个用户。有没有比图中所示更好的方法来设计类以消除冗余？

Answer 1

• 你有冗余，而且非常棒，因为你没有选择导航方向。无箭头关联意味着在两个方向上的关联。您可以使用它有时，但不能在所有连接上使用它！如果订单只有单向导航到付款和用户，则问题就会消失。
• 您尚未关联购物车和订单。通常它们紧密相关1：（0..1）。或者将Order设置为购物车的概括。购物车需要约会？真？但订单应该有更多信息 - 信息，交付和事物。或订阅有一些特殊的逻辑？那你也没有。
• 而不是单词'contains'使用聚合 - 共享和组合。
• 'has'应由dot / end ownership显示，而不是以文字显示。你拥有它们，谁拥有谁？
除了关联之外，
• 'activates'应该作为依赖项显示（如果存在的话）。
• 我的建议是划分用户帐户（仅限识别/登录需求）并使用信息（地址和其他内容）。
• 订单中的商品和商品更贴心。使用泛化，而不是'是'。此外，订购后订单中的项目克隆并获得固定价格。那是哪里？

实际上，图表的逻辑根本不明显。考虑制作更高级别的图表。状态机甚至用例开始。