0

We have set of common types (mostly structs, scalars, string IDs) that are used across different packages in a project written in Golang. Currently we define them in a package named "models" in the root of the project. It was made to reduce cohesion of different packages and to avoid circular dependencies. Is it considered as good practice to achieve these goals this way? If no, what are the alternative approaches?

Improve this question
4
  • 1
    Cohesion is usually considered a good thing - are you sure the designers intentionally decreased it?
    – Kilian Foth
    Apr 14, 2021 at 11:25
  • @KilianFoth , maybe I've used wrong term. I meant that we strive to make packages not depend from each other, but from abstract interfaces (that are defined where consumed) and common things. That let us keep the package dependencies graph simple.
    – oare234
    Apr 14, 2021 at 13:17
  • @KilianFoth , so the sake of the question is: what is the best practice to manage such "common things", and is keeping them in the single package "models" considered as good practice?
    – oare234
    Apr 14, 2021 at 13:20
  • @oare234, where I work we generally create a module called lib with all of the shared packages. We also follow a release process to version them so we can do a go get ... if needed with the changes we are after.
    – kaizenCoder
    Nov 18, 2021 at 4:00

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.