What is the idiomatic Go approach to writing business logic for CRUD involving multiple tables/models?

I am refactoring my backend where clients can start threads and make replies. I keep a 3-layer architecture with thin handlers that bind and validate, service layer with all business logic, and a repo layer. When a reply is created I need to check filters, create the reply, link media attachments, and update the thread's reply count. In certain cases I also need to log a system action such as when a user hits a filter, the admin/owner should see a reason why a reply was blocked.What I currently have is a separate service PostingService that injects the RepliesService, ThreadsService, FiltersService, and LogsService, to calls their respective methods:

func (s *Service) CreateReply(ctx, req) (resp, error) { // more business logic such as checking filters, bans, etc. s.repliesSvc.CreateReply(ctx, req.User.ID, req.Message); s.threadsSvc.UpdateReplyCount(ctx, req.ThreadID); } 

For reference I keep my services in a folder

infra/ postgres/ threads.go reply.go models/ thread.go reply.go services/ posting/ service.go threads/ service.go repo.go replies/ service.go repo.go 

I want to keep it simple and not over-abstract, but without a separate posting service I risk circular dependencies between threads and replies. Is this the idiomatic Go approach?

submitted by /u/Mundane-Car-3151
[link] [comments]