Transitioning application packages to library

[Jiraffe7]

Hi @benbjohnson

Follow up questions after reading https://www.gobeyond.dev/packages-as-layers/

1. How would you transition a package dependent on the domain package to a library that can be reused by other projects?
2. By doing so, your project now has a dependency on the library. How would you then invert the dependency?

Appreciate your articles and this repo! They have shed much light to a beginner golang dev.

[benbjohnson]

Hi @Jiraffe7, thanks for the question. I think it's tough to say without seeing a concrete example.

In that situation, I find there's usually one of two things happening:

1. Your extracted library is more generic than your application domain so it probably should be a library. An example would be if you had a file format encoder/decoder in your application that other applications would benefit from using. In that situation, it makes sense that your application would depend on the library so I don't think you need to invert the dependency.

2. Your extracted library is being shared by two applications that share the same application domain. I find this happens in microservice applications a lot. An example would be an accounting microservice and an e-commerce service both depend on a Customer type and related functionality.

If you're in situation number 2 then you have a couple options. You could combine the microservices into one application. You could continue to have separate repositories for both microservices and they depend on a third repository for the common domain types. You could also combine into a monorepo and have subdomain packages for each application.

For example:

myapp/                     # Common application domain
    accounting/            # Accounting subdomain
    ecommerce/             # e-commerce subdomain
    user.go                # User domain types

This option is good when you have a lot of services and you want to treat them as independent applications. Each one can be isolated and even have their own cmd subdirectory. They can then depend on the higher-level common application domain for more generic types (e.g. User).