Packages interdependencies

[leogr]

The current situation is:

• messages needs core
• schemas needs core
• resources needs core and schemas

Questions:

1. What are best practices to avoid import cycles?
2. Should a package avoid to import a package that's parent in path?

Refs #9

[leogr]

schemas could be empty, I've began to move contents away by https://github.com/fabbricadigitale/scimd/commit/8e27fa65095c29852d149a457bf9a31b7269e690

[leogr]

I had some thoughts, finally I described my idea below.

Package's rules of thumb

1. If a subset of a package is self-contained (*), it SHOULD be moved to its own new package.
2. A descendant package SHOULD be more specialised than its ancestor.
3. A package MAY import any other packages but MUST NOT import its descendants.
4. When a importing cycle still occurs, the less specialised package MUST be refactored to avoid importing the more specialised one.

(*) has no interdependencies with other parts of the packages

Some examples:

• data_types.go (that's self-contained) may have its own package: schemas/datatype, so we could write datatype.New(...)
• attributes definition and decode.go may have its own package: schemas/attribute that just needs datatype
• mapped resources may be moved to schemas/resource that needs datatype and core
• Common, Schema, ResourceType, ServiceProviderConfig will be left in schemas/core
• api must not import api/messages, so may be messages needs some siblings
• validation as first level is OK
• server as first level is OK
• client as first level is OK ...and so on

cc @leodido @alelb

[leodido]

:+1: