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?

3
  • 1
    Cohesion is usually considered a good thing - are you sure the designers intentionally decreased it? – Kilian Foth Apr 14 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 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 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.