Aspect files are a good way to apply the same structure to different parts of the architecture. This section demonstrates how to deal with connections from aspects to artifacts that are outside of the scope of the aspect itself. Let's say, we want to control the access to java.lang.reflect and only allow access to it from the artifact "DataServiceInterface" defined in "component.arc". It is shown why a first naive approach is not working, and how the goal can be achieved using the "require" feature.
-
Add the following artifact to this file:
artifact Reflection { strong include "External [Java]/[Unknown]/java/lang/reflect/**" } -
Save the changes and check the assigned elements to the generated instances of the artifact "Reflection". Since there is only a single java.lang.reflect package, the contained types are matched once for the first instance of a "component", and then there are none left to be matched for further "Reflection" instances in other components. This is clearly not what is needed. We want only a single instance of the "Reflection" artifact.
"strong include" matchers are disabled in aspects, to avoid accidental misuse and the above mentioned strange matching results. This is the reason why no matches are shown for any or the created "Reflection" artifacts.
-
We need only a single instance of the "Reflection" artifact in the application architecture. The above approach is not working, and it is now demonstrated how it can be achieved with the "require" feature. You need to define the "Reflection" artifact in its own file, let's say "reflectionAccess.arc". You can remove "strong" from the include matcher.
-
Open the architecture file "application.arc" and add the following statement at the bottom:
apply "./reflectionAccess.arc"
This creates a single "Reflection" artifact at the top-level of the architecture check.
-
Go back to "component.arc" and add the following statement at the top of the file:
require "./reflectionAccess.arc"
This now allows using artifacts contained in that file, but does not instantiate them again. Do not forget to define the allowed connection between "DataServiceInterface" and "Reflection".
-
Save the changes and check again for the generated "Reflection" instances in the Architecture view. There is now only a single instance and when you open the Exploration view for "application.arc" you can check which dependencies to "Reflection" are allowed and which represent violations.
This concludes the architecture modeling. It is recommended to read the remaining chapters describing the architecture model, e.g. Section 11.10, “ Artifact Classes ”, for even faster architecture modeling.
End of Step 7 (step7_crm-domain-example.sonargraph).
Related topics:
