我正在编写一个基于微服务的小型应用程序。其中一项服务的任务是查询外部API和处理JSON响应（房屋的过滤列表）。由于我正在使用协议缓冲区来序列化将发送到消息代理的消息，因此我需要将JSON输出转换为适当的协议缓冲区格式。
这是说明整体架构的图：
问题在于，由于JSON响应较长，分页并且还具有许多嵌套字段，因此没有简单的方法来手动创建相应的ProtoBuff消息结构。
我可能会以文本字符串形式发送JSON响应，并在数据库服务端进行处理，但这随后带来了如何在数据库中存储每个房屋对象以便稍后查询的问题。
将整个响应解组为Go结构会带来与尝试首先创建ProtoBuff消息结构相同的问题。不能将其作为原始JSON字段存储在数据库中，因为我需要能够查询某些字段并实际上从响应主体中提取每个房屋描述。
此外，创建与数百个不同字段和嵌套对象匹配的数据库架构，似乎是一种非常繁琐的处理方式。
在许多Web服务上处理大量JSON输出时，最佳实践是什么？
There is no clear reason on why to convert the JSON format in the message broker. Probably, leaving it a JSON object through the message broker is the way to go.
In terms of how deep you should model it, it depends on several factors. Here are some hints:
The storing decision also depends on multiple factors (check the following articles and questions about Relational vs. non-relational 1, 2 and 3 - and there is much more available). You should have in mind that relationship databases (such as MySQL) are used to store relations.
我认为您的问题在微服务中并不特别。关于如何使用外部模型。通常，直接使用并持久保存外部模型不是一个好主意。从域驱动的设计角度来看，外部模型属于另一个域上下文。通常，拥有一个反腐败层将外部模型映射到您自己的模型是有益的。这样，您可以将模型与外部模型分离。
This anti-Corruption Layer got pattern name "Ports & Adapters".
当您拥有自己的模型时，应将此模型与系统中的其余模型对齐。