Plugin for SonarQube to validate devonfw architecture.
With devonfw you can build business applications very efficient following elaborated guidelines and best practices. This includes a profound architecture blueprint that is mapped to the code via clear packaging conventions.
This sonar-devon-plugin provides a plugin extending SonarQube with the ability to validate your code according to the devonfw architecture.
If you have SonarQube installed, you only need to download and copy the latest version of this sonar-devon-plugin into the extensions/plugins folder of your SonarQube installation.
Further you need to import the devonfw quality profiles (or active all the rules of this plugin in your quality profile).
For further details read the SonarQube setup guide
In your project add a file called architecture.json to the toplevel directory of your project and configure your components and their dependencies. You should commit this file to your version control system (e.g. git). The following example shows an architecture definition for the my-thai-star sample application:
{
"architecture": {
"components": [
{"name":"bookingmanagement","dependencies":["ordermanagement","usermanagement","mailservice"]},
{"name":"dishmanagement","dependencies":["imagemanagement"]},
{"name":"imagemanagement","dependencies":[]},
{"name":"ordermanagement","dependencies":["dishmanagement"]},
{"name":"usermanagement","dependencies":[]},
{"name":"mailservice","dependencies":[]}
]
}
}As you can see all you need to do is declare the components of your application with their allowed dependencies. In case you need dependnecies to other devonfw apps (microservices) you can also add the as dependencies with qualified packages (e.g. com.devonfw.sampleapp.samplecomponent). As the technical architecture is standardized by a blueprint in devonfw you do not need any further configuration and everything can already be validated out of the box.
The following image illustrates the devonfw architecture rules. The arrows show the allowed dependencies in green, discouraged dependencies in orange and forbidden dependencies is red.
Within the same component you are always allowed to call code from the same layer and scope as well as the API from the next layer below. Discouraged and forbidden dependencies are always implemented by its own SonarQube rule. This gives you absolute flexibility to customize the severity of such architecture violation. These dependencies have a white circle with a unique label. For each label we link the according rule to give you transparency and help you customizing.
The following component rules will rely on the architecture.json configuration decsribed above.
Further there are aditional rules to check the scope:
Additioan, there is a generic rule that checks the devonfw packaging conventions:
Finally, there are rules checking the proper usage of third-party library code: