I often work on developing Temporal Worker services in Go, but I still find it difficult to decide how to structure the codebase in the cleanest and most maintainable way.
For my standard REST services, I implement the following architecture with the following layers:
- Transport (package api)
- Service (package services)
- Adapters (package adapters)
I have tried many times to write a Temporary Worker with this architecture, but I often come across the fact that the Service layer depends too much on the API layer.
I would like to get recommendations on how to implement the correct Temporary Worker code architecture in Go.
It is a mistake imo to conflate the transport or service with the structure of the project. I normally have my various Activities spread throughout the codebase and I import them in a single StartWorker() that registers workflows and activities and starts the temporal worker. The temporal imports are everywhere, yet one import will have temporal in the name and identify itself thus.
This allows my API interfaces to be an internal/types or a types.go in a module. If two modules need the same type, that’s because there is in fact a dependency probably marked with an “import internal/user” or whatever at the top.
So I write a normal Go program and my app.Entrypoint() which main() calls calls StartWorker() (or if I didn’t properly segment it, the StartWorker() I describe is in my main module. that’s my cheating-draft-quickie approach).
Thank you for answering!
Could you show the folder structure of your Temporal Worker project, please?