Provide more abstract concept than the package level for describing the target architecture

[gunnarmorling]

Currently the target architecture to validate a code base against is described in terms of allowed package references. This does the job, but it is desirable to have the possibility to describe the architecture in more coarse-grained units, i.e. "components" (which may contain one more packages). My current thinking is along these lines (using JSON as a notation, could be a DSL or anything else of course):

{
    "components" : [
        {
            "name" : "COMPONENT_1",
            "contains" : [ list of package name patterns, ... ]
            "reads" : [ "COMPONENT_2", "COMPONENT_..."]
        },
        {
            "name" : "COMPONENT_2",
            "contains" : [ list of package name patterns ]
            "reads" : [ "COMPONENT_3", "COMPONENT_..."]
        },
    ],
    # whitelist as today; that's an implicit component containing the given packages which is read by all other components
    "whitelisted" : [

    ]
}

The current design is just a special case of this model, with a 1:1 relationship from component to packages. In that suggested model, an error will be raised, if one package is matched by the expressions of more than one component.

[gunnarmorling]

The ANALYZE mode should be expanded with a new option, which takes a list of (name:pattern) tuples describing components to be created in the generated descriptor (similar to the existing whitelist option).

[gunnarmorling]

A related question is whether we should go below the package level for the architecture description. I can see how some people would like to have that capability, although I personally don't find it too valuable in practice (e.g. I wouldn't mind having a cycle between two classes in the same package).