考虑以下情况。
三个应用程序A，B和C必须合作：A是外部第三方应用程序，而B和C是内部应用程序（因此我们可以控制B和C，而不是A）。 B使用C和B本身包含的逻辑回复A提出的请求。将B视为A和C之间的层。
A，B和C有一些基本的共同概念可以理解和使用。
假设此处的关键任务是将所有内容分离，因此如果明天我们要使用A1而不是A，则B和C之间的所有交互都保持不变（并且，如果我们想要使用C1而不是C，则B和A之间的相互作用保持不变）。
问题是关于B和C的数据模型设计。我想到了两个解决方案：
有没有处理这种情况的最佳做法？有没有替代1.和2.？ 1和2都有任何内在问题。？
修改 根据要求，我会尝试给出一个更明确的例子（当然这里的一切都是虚构的。也原谅我可怕的幻想）。
ACME ltd是一家二手车零售公司，需要有关购买和转售的每辆车的详细信息。这个过程是外包的，所以他们公开了一个简单的DTO，它有两个类ACME.CarInfoRequest和ACME.CarInfoResponse（包含适当的字段）。特别是ACME.Car的商业概念。
ACME正在外包给汽车数据提供商INITECH inc。 INITECH拥有一个包含汽车信息的大型更新数据库，并且还具有与警方记录的实时连接，以检查汽车是否被盗。 INITECH有一个主要应用程序与客户交互，并使用不同的应用程序与警方沟通：INIMAIN应用程序和INIPOLICE应用程序。这两个应用程序都有“汽车”的基本概念。
问题是：INITECH应该使用共享数据模型，让INIMAIN和INIPOLICE将其添加为依赖项，还是应该在两个应用程序中实现镜像？ 换句话说，这两种解决方案可能是：
1）INITECH建立INIDATA项目。 INIDATA包含INIDATA.Car来表示“汽车”的概念。 INIMAIN和INIPOLICE都将INIDATA添加为依赖项并使用相同的INIDATA.Car。当INIMAIN和INIPOLICE谈论“汽车”时，不需要翻译（因为它们都指的是同一个INIDATA.Car）。另一方面，INIMAIN通过适配器将ACME.Car中包含的信息映射到INIDATA.Car。
2）INIMAIN有自己的INIMAIN.Car表示（分别是INIPOLICE INIPOLICE.Car）。当INIMAIN希望INIPOLICE询问有关汽车的信息时，请先将INIMAIN.Car翻译为INIPOLICE.Car。然后，当INIPOLICE回复时，INIMAIN会将所有内容从INIPOLICE.Car转换回来
INIMAIN.Car。当然ACME.Car仍然通过适配器映射到INIMAIN.Car。
希望现在更清楚了（即使可能这个例子很尴尬，再次原谅我有限的幻想）。
答案 0 :(得分：1)
问题是：如果INITECH使用共享数据模型，让INIMAIN和INIPOLICE将其添加为依赖项，或者应该在两个应用程序中实现镜像
此问题的答案取决于 INTECH 计划向其客户提供的服务列表。
INIMAIN和INIPOLICE模块共享一个{{{ 1}}域模型（因为只需要支持一种数据模型，即INDATA.car将与之交谈的外部警察应用程序理解的数据模型）INPOLICE模块提供更多服务，例如汽车的保险详情，那就更有意义了CARINSURANCE和INPOLICE模块有自己的数据模型，根据他们所说的外部服务建模（警察记录外部服务和保险记录外部服务通常有自己的请求模型）。在这种情况下， INTECH 应该有CARINSURANCE和INDATA.PoliceCar个数据模型，而INDATA.InsuranceCar会将INMAIN映射到ACME.car或{{ 1}}取决于INDATA.PoliceCar 这一切都归结为 INTECH 是否计划向其客户提供单一服务或多项服务。如果在不久的将来很难确定这一点，那么坚持使用INDATA.InsuranceCar和ACME共享的单个数据模型更有意义，而不是过度设计的用例INTECH 可能永远不会遇到。