Are there any good source code with archunit tests against SOLID, GAS, GRAP etc..

[nagkumar]

We all know the best design principles are laid in

SOLID
DRY
GRASP
KISS
YAGNI
CUPID
Gang of Four

and many others at..

https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o

Are there any good ready-to-use archunit architecture rules, that be used along with the source code.. to understand them better..

Maybe it is good have a repo of archunit rules that are generic enough and reusable.. looks like a big project by itself repo of arcunit rules..

Is my understanding that most of the rules of archunit are generic enough or can be written for frameworks like structs, spring etc.. that can be used as is or with light modification in many projects/products is it true..

[nagkumar]

Also, I think most of the lint rules can also be brought in as archunit rules..

[codecholeric]

The question is, if this isn't "using a hammer for a screw" so to speak 🤔 I'm just wondering if there are not way better tools out there for that use case?

[nbrugger-tgm]

How would you define rules for Kiss, what is "simple" in terms of rules? Loc per method max depth of call trees / max call stack depth? I think theese rules are too generic to be rules. I think the rules that ppl create with ArchUnit already lead/work towards principles like KISS

[codecholeric]

I also think that many of these sorts of principles either need to be translated more towards code or they are plainly not testable this way. Take SOLID, what do the principles mean when looking at plain code? I can't write a rule classes().should().haveSingleResponsibility(), but I would need to define how I see this from the code. And I'm not sure if that is really possible in a programmatic way?
Or YAGNI, how should ArchUnit ever know if what you write is something you will need later on? I think these things can only be found by things like 4-eyes principle, i.e. they need to be covered by software development methodologies, not tools 🤔

I think what you can share with ArchUnit are concrete rules about the code structures. I.e. what components do we have, how do you identify them, how should they be in relation to each other, what patterns to we have, etc. By building a net of rules you can achieve higher consistency and maintainability. You can also share generic blueprints for such things, e.g. what we do with layeredArchitecture(). But there will always be parts that are not automatically testable, e.g. "do my components even make sense", or "did I put the right responsibility into the right component", or "did I not (over-/under-)engineer the solution for the problem at hand". These are the parts where experience, creativity, teamwork, etc. come in. And I don't think these parts will be coverable by a tool like ArchUnit (beyond some crazy AI kicking in in some years 😁).

[nagkumar]

True, not all can be standardized, however whatever is possible mostly by frameworks can be worked on i.e. enahcing further the ones that can get into archunit library.

In the context of AWS well-architected cloud, spring, quarkus solutions few parts may already comply to SOLID etc.. therefore archunits in the context of framework and popular standards can be a better way to promote archunit.

Do understand, if the code is completely self written and not a standard, may be there is no option but to write archunit rules too.