英文:
How to design a multi-file processor using Golang?
问题
我正在尝试设计一个可以处理多种文件格式的服务，例如使用微服务：
我有一个客户使用文件格式A，另一个客户使用格式B，还有其他客户使用格式C。
在处理每个客户的特定格式之后，我需要将该格式转换为一种通用格式，并插入到数据库中。
我尝试的第一件事是为每个客户设计一个服务，但它们都需要了解基本格式，如果需要更新基本格式，我需要更新所有这些服务。
我正在尝试解耦服务处理器，并有一个单一的地方来转换为基本格式。
如果我的客户服务了解基本格式，如果该格式发生变化，我需要更新所有这些服务。如果我有一个翻译格式的服务，这个服务需要了解所有客户的格式。
如何设计这个解决方案？
英文:
I'm trying to figure out how to design a service that can handle multiples files format, using micro-services for example:
I have a customer using a file format A, another using format B and other using format C.
After processing a specific format for each customer, I need to transform this format into an common format, and insert into database.
The first thing I tried is to design one service per customer but all of them need to know the base format and if an update is needed in this base format, I need to update all of there services.
I'm trying to decouple the service processor and have a single place to translate to base format.
If my customer services know about the base format, if this format changes, I need to update all of them. If I have a service that translate the format, this service needs to know all customer formats.
How to design this solution?
答案1
得分: 1
首先，根据你的应用程序目的，规划内部数据格式，确保它对后续操作来说是方便的。所有应用程序都应该使用内部数据格式，只有特定的输入输出适配器需要了解特定客户的格式。
然后编写适配器，将自定义的数据格式A、B、C等转换为基本的内部格式。这些适配器应该尽可能地轻量化，只需进行数据转换，不要添加过多逻辑。这样更容易进行维护。
你是对的，如果更改内部格式，就必须重新审查并可能更改所有适配器。这就是为什么它们应该非常轻量化的原因。
考虑一下默认值可以是什么？
我建议从几个客户格式开始，以调试所有概念。
将解决方案设计为一组微服务还是单个单体架构中的模块，在这种方式下并没有太多意义。
英文:
Plan internal data format to suit purpose of your application first, it should be convenient for next operations. All the application should work with internal data format and only specific input-output adapters should know about specific customers formats.
Then write adapters from custom data formats A, B, C, ... to convert to basic internal format. These adapters should be as thin as possible, they should have minimal logics - just convert data and nothing more. This way it will be easier to maintain them.
You are right - if you change internal format you have to review and possibly change all adapters. That's why they should be very thin.
Think which defaults can you have?
I recommend to start with few customer formats to debug all concepts.
Wheather make the solution as a set of microservices of as modules in a single monilith - has no much sense in this way.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论