Organizing service methods that require multiple dependencies

[seankay]

I'm curious how one would organize a service that requires multiple dependencies to carry out an operation. For example if I had an Attachment resource where the attachment binary (image, video, etc.) had to be stored on S3 and its reference stored in a persistence layer like postgres. Would you have an s3 package and a postgres package both implement the AttachmentService interface and one wraps the other? If so, how would we determine which package wraps which? My concern with this approach is that the correct implementation of atomically storing an attachment in two places is spread across multiple packages.

s3AttachmentSvc := s3.NewAttachmentService()
attachmentSvc := postgres.NewAttachmentService(s3AttachmentService)

attachmentSvc.create(&Attachment{...}) // atomically stores on s3 and pg

Thanks for creating this project and its accompanying articles. I enjoyed your earlier articles, and I've used this pattern for many of my and my company's Go projects!

[benbjohnson]

Hi Sean,

I would probably wrap it how you have done there with postgres wrapping s3. That seems intuitive to me although you could do it the other way around.

I'm not sure you can necessarily make the operation atomic. Regardless of the order you wrap them, if it fails halfway through, then you'll have the attachment stored in only one place. You could have a cleanup operation that removes objects from S3 that have not been persisted in Postgres to fix that though.

[Jiraffe7]

Is there a reason why this type belongs in the root package instead of a separate package that implements the domain?

[benbjohnson]

I use the root package for the application domain but you can put in a different domain package as well. It doesn't have any dependencies outside the application domain so that's why I put it there.

[Jiraffe7]

Thanks Ben!

[tsvobo]

Hi @benbjohnson, thanks for the article. I have followup questions about this - let's say I need to extract the business logic to a separate package to reduce the complexity within the root package (i.e. too many domain objects and functions with business logic). It cannot be moved either to http or to sqlite packages.

First question - what would be the best name for this package with business logic? I wasn't able to come up with a name that would properly fit naming based on this layout. I was thinking about service (as a service layer used in other languages for this purpose) but it doesn't feel right to me.

In addition to that, what do you think about client/httpclient as a proper name for a group of HTTP clients (again used by the service layer functions)? Or would you suggest merging them with the http package (though risking some cyclic dependencies or "interface hell" between various packages)?

Thank you!

[benbjohnson]

@tsvobo Sorry for the late reply.

what would be the best name for this package with business logic?

That's usually the hard part about moving application domain functionality out of the root domain package. I honestly don't have a great answer. I tend to grow my domain package and not worry about it too much but if I do move code out then I name it on a case-by-case basis.

what do you think about client/httpclient as a proper name for a group of HTTP clients

I personally dislike the name client for the package because you probably have a Client inside of there. Where I put the client depends on the application. For small apps that have a server binary & a CLI binary bundled together and the application is its own client, then I'll put the client code into my http package.

If I have a third party application that needs to use my wtf application, however, I typically create a separate repository called wtf-go and implement the Go client there. That naming makes it easy to add a Ruby/Java/etc client later. On import, the client would typically alias it to wtf and the naming would be wtf.Client which makes sense to me.

If I am separating out a separate repository, though, I don't share any code with the main wtf repo. I find the dependency hell isn't worth it. You can generate clients via Swagger or gRPC if you need to but those can be ugly.