#6: implemented naming convention tests N3 & N4

[zichriste]

Due to missing classes needed by naming convention rules N1, N2, and N5 to N8, the implementation of these rules has not been handled in this task.

[hohwille]

@zichriste Thanks for the PR. Excellent. Simple and straight forward-solution (was more complex in sonarqube due to lack of inheritance check). 👍

Due to missing classes needed by naming convention rules N1, N2, and N5 to N8, the implementation of these rules has not been handled in this task.

Let us simply add a TaskListCto derived from AbstractCto. I can not do that before Thursday, but then I should find some time to extend our demo app.

What we can still discuss: First of all I like it to have separate JUnits for the different types of rules (Separation of concerns). However, I have seen projects putting all arch-unit checks always into a single JUnit. Does this have any performance-impact due to caching? If not, I would love to stay with your approach and we could already merge this PR as is.

[hohwille]

We are on the finishing line with PR #10
To follow CI best practices, I would first merge PR #10 that comes with a green build pipeline.
After the merge, I can update this PR so the build will also become green and I will click merge here :)

[hohwille]

@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

[hohwille]

Now green, hence I am merging :)