A scan only imports "raw" data into the graph database, in case of Java it just represents the structure of the bytecode with elements like packages classes, methods, fields, annotations or invocations.
The purpose of concepts
is to enrich this information with higher level abstractions, e.g. a node representing a Java class annotated with @Local
is labeled with Ejb
and Local
for easier usage by other concepts or constraints. Those then can just rely on the label Ejb
to perform checks, e.g. for correct location in service layer packages. These themselves would have been labeled by a concept according to project specific naming rules:
[[adr:ServiceLayer]]
[source,cypher]
.The package named `service` within the root package represents the `Service` `Layer`.
----
MATCH
(root:Package)-[:CONTAINS]->(serviceLayer:Package)
WHERE
root.fqn = "my.project.root"
and serviceLayer.fqn = "service"
SET
serviceLayer:Service:Layer
RETURN
serviceLayer as `Service Layer`
The constraint would now depend on both concepts and use a query like this:
[[adr:EjbsMustBeLocatedInServiceLayer]]
[source,cypher,role=constraint,requiresConcepts="ejb:*,adr:ServiceLayer"]
.All EJBs must be located in the service layer.
----
MATCH
(ejb:Ejb)
WHERE NOT
(:Service:Layer)-[:CONTAINS*]->(ejb)
RETURN
ejb as `EJB Outside Service Layer`
----
Concepts must be applied explicitly, usually they are defined as dependency: