我们有以下情况。我们有几个存放文件的存储库。我们编写了前端服务，处理不同存储库中的文档和文档数据。我们的操作允许您（其中包括）存储新文档和检索文档元数据。
问题是，存储库中有不同类型的文档，每个文档都有不同的元数据集。例如，一个存储库中的所有文档都包含文档名称，添加日期，大小，ID，文档类型和文档源。开票凭证还包含开票帐号和客户名称。政策文件包含保单号，保险名称和代理商代码。一些特殊的政策文件也有生效日期和包类型。
在第二个存储库中，文档包含文档名称，添加日期，大小，类型和位置。发票（在另一个存储库中是开票凭证）具有帐号和客户名称，还有发票日期。政策文件包含保单号，保险名称，代理商代码，生效日期和政策类型。一些特殊的政策文件有取消日期和到期金额。
现实情况更为复杂，但这代表了我所拥有的基本问题。
我无法控制现有的元数据字段。这些是在其他地方定义的，也包括其中的一些遗产。此外，这些是SOAP Web服务，但最终将变为RESTful。但就目前而言，它们是由WSDL定义的。
那么，代表这些具有许多相似之处的东西的最佳方式是什么，但存在一些差异？
一些注意事项：
我可以选择一个带有所有可能字段和枚举的大胖对象来区分它们，但这意味着客户必须神奇地知道哪些字段适用，哪些字段不适用。
我可以为每个可能的文档字段集合使用特定对象，但是客户端必须知道文档是来自还是来自特定存储库，这比我希望他们知道的更多。
现在，我已经选择了两个世界中最好的（或最差的？），进行了一些高级抽象（政策文件，结算文件），转换到我可以的地方，留下任何未知或未定义的该抽象的数据为空。
但这意味着客户仍然必须知道，例如，对于某些结算文档，您将拥有发票日期，但对于其他人则不会。或者，对于来自一个存储库的文档，您将拥有一个ID，但对于另一个存储库，您将拥有位置。
无论如何，我正在寻找处理这些类似但不同对象的最佳实践。
答案 0 :(得分：1)
那么，代表这些具有许多相似之处的东西的最佳方式是什么，但存在一些差异？
我认为如何表示/建模数据的方法取决于您的应用程序要求，并且我不知道全球公认的最佳实践，一些（所有？）选项是：
一些注意事项：
我希望尽可能地保护客户端免受特定于存储库的信息的影响。在完美的世界中，客户不应该关心文档是来自一个存储库还是另一个存储库，尽管不同的字段可能会使这成为一个梦想。
这是一个业务问题，而不是技术问题，通过丢弃不必要的字段来规范化数据，将它们声明为可选，并且应该预期有时为空，如果它们是从其他公共属性派生的，则计算缺失值或与您拥有同一文档的不同子类型（BillingDocRepo1，BillingDocRepo2）
我想要一个newDocument和getDocumentProperties调用来接受并返回每种类型的相关数据，而不是为每种不同的文档类型分别进行new和get调用。
这在所有表示中几乎都可行，REST和SOAP Web服务都支持继承和多态，如果使用动态模式（例如地图或带元数据的类），也可以使用