Implement Naming-Convention Rules

[hohwille]

Implement the Naming-Convention Rules.

Acceptance-Criteria:
The following rules are implemented:

• N1 - Cto
• N2 - Dao (obsolete)
• N3 - Entity
• N4 - Eto
• N5 - UseCase
• N6 - SearchCriteria (not needed for our simplified samle, give projects more freedom of choice)
• N7 - To (same as above)
• N8 - did not even exist in sonar plugin
• N9 - Repository

Please consider other options that ArchUnit and/or Exceptions and build-breakers for this. Instead we should get warnings for these violations. Totally awesome would be to have something like "custom checkstyle rules" that could run in IDEs like Eclipse or IntelliJ and mark violations with warning icons and according message. However to start simple and get this done, we can use some kind of reflection infrastructure (ArchUnit, Classgraph, org.reflections) to implement the check of the naming conventions manually and then log ERROR message but keep the test green and the build successful if naming conventions are violated.

BTW: Unfortunately there is no Java standard for rules that can do static code analysis that would be used by checkstyle, pmd, findbugs, sonar-qube, etc.
The de-facto-standard still is sonar-qube but as we have seen the ecosystem is fragile and maintenance of such rules as plugin is rather tricky.

[hohwille]

reopening after auto-close from PR as PR #11 did not implement the entire story.

[hohwille]

Cite from #11:

@zichriste For the record: I found some minutes to extended our little sample app to come with a CTO example as well so N1 can be implemented now. Also for N5 I introduced AbstractUc.
You may implement and add N1 and N5 either as part of this PR or after merge as new PR.
We do not need the other checks so that would complete the story #11 then:

• N2 DAO (Data Access Object) is an alternative to Repository and you will never have both in the same app
• N6 we do not have SearchCriteriaTo in our sample and though this may be a common construct I do not see the need for our demo to show it. If later requested by users, it can still be added.
• N7 is even less important

I also found a tiny "typo":
PR #12 nicely demonstrates that the checks work and give understandable error output:

Error:  Failures: 
Error:    Architecture Violation [Priority: MEDIUM] - Rule 'Layered architecture considering all dependencies, consisting of (optional)
layer 'common' ('..common..')
layer 'logic' ('..logic..')
layer 'dataaccess' ('..dataaccess..')
layer 'service' ('..service..')
layer 'client' ('..client..')
layer 'batch' ('..batch..')
where layer 'client' may not be accessed by any layer
where layer 'batch' may not be accessed by any layer
where layer 'service' may only be accessed by layers ['client']
where layer 'logic' may only be accessed by layers ['service', 'batch']
where layer 'dataaccess' may only be accessed by layers ['logic'], because Dependency of technical layers violates architecture rules.' was violated (2 times):
Class <com.devonfw.sample.archunit.task.archunitviolations.NamingConventionEntityViolation> extends class <com.devonfw.sample.archunit.general.dataaccess.ApplicationPersistenceEntity> in (NamingConventionEntityViolation.java:0)
Constructor <com.devonfw.sample.archunit.task.archunitviolations.NamingConventionEntityViolation.<init>()> calls constructor <com.devonfw.sample.archunit.general.dataaccess.ApplicationPersistenceEntity.<init>()> in (NamingConventionEntityViolation.java:11)
Error:    Architecture Violation [Priority: MEDIUM] - Rule 'classes that are assignable to com.devonfw.sample.archunit.general.dataaccess.ApplicationPersistenceEntity should have simple name ending with 'Entity', because Classes extending ApplicationPersistenceEntity must follow the naming convention byending with 'Entity'.' was violated (1 times):
Class <com.devonfw.sample.archunit.task.archunitviolations.NamingConventionEntityViolation> does not have simple name ending with 'Entity' in (NamingConventionEntityViolation.java:0)
Error:    Architecture Violation [Priority: MEDIUM] - Rule 'classes that are assignable to com.devonfw.sample.archunit.general.common.AbstractEto should have simple name ending with 'Eto', because Classes extending AbstractEto must follow the naming convention by ending with 'Eto'.' was violated (1 times):
Class <com.devonfw.sample.archunit.task.archunitviolations.NamingConventionEtoViolation> does not have simple name ending with 'Eto' in (NamingConventionEtoViolation.java:0)

However, reading carefully shows that a space is missing in byending.

Another thing that is slightly confusing is because Dependency of technical layers violates architecture rules.' was violated (2 times): ....
You have put the violating classes in the "wrong" package so that you are not only violating the naming convention but also the layer rules. I would prefer if the PR #11 will only focus on the naming rules.