备注:当问题有UML标记时提供答案(最后一部分仍然有效)
您的图表中存在多个问题:
- 参与者是系统外部的分类器。因此，类不能与参与者关联。
«use»依赖项应该用虚线箭头表示，而不是平线箭头。- 不清楚你的
«Representation»类和你的»«DB table»代表之间的链接是什么:它又是一个依赖关系吗?它是一个可航行的联合体吗? - 一个名称有多个定义，没有任何消除歧义的可能性。
如何在UML中实现?
在UML中，在相同的名称空间中拥有两个具有相同名称的类是无效的，因为它不清楚指的是哪个类。
然而，你可以调整你的模型并分离不同的类族，将它们包含在不同的包中，例如Database,CRUD,Consumer。
包定义了一个命名空间。因此，对CRUD包中Product的所有引用都将引用相关的CRUD类。
对于不同包的类之间的关系，您可以使用限定名(即包括包名)来消除歧义，或者，在没有冲突的情况下，通过将一个包导入到另一个包中。
这是设计API的最佳方式吗?
管理端点中冲突的名称并不理想。这很容易引起混淆。当然，您可以找到技术解决方案来解决这个问题，但是，为什么要这么做呢?
为什么不让客户端根据需要剪裁/简化数据(例如，默认使用用户的语言，除非有其他要求)?
为什么不让端点查询参数提供一个可选的语言代码来过滤返回的语言集呢?
或者为什么不用不同的名字来称呼不同的事物呢?我在想ProductLocalized还是ProductShort?
这是命名问题还是我接近建模不正确?
听起来像是命名问题。
从相同的底层数据派生多个资源是完全合理的。
但是每个资源都需要有自己的标识符。机器并不特别关心标识符是什么，所以您可以使用…
/b6d5cc6a-e4b3-4bc9-90d0-723f1d8ee22a
/5952d730-d447-4537-9bf0-74cdc2f9f79a
但是人类通常用人类可读的标识符更好地复制。
任何与本地约定一致的拼写都可以。
一种可能是直接将观众的名字编码到标识符中
/storeOwner/products/123
/shopper/products/123
或者您可以选择与业务功能更接近的名称
/inventory/products/123
/sales/products/123
你可以自由选择你想为哪些人优化(领域专家?操作员正在读取访问日志?技术作者记录api?远程开发人员使用它?等等)。