Java SOLID Review

Scope

Treat SOLID and object-oriented design rules as heuristics, not automatic mandates.
Prefer maintainable, testable, intention-revealing, simple local designs over pattern-heavy code or hypothetical abstractions and optimizations.
Apply project conventions and more specific Java skills first when they are relevant.
Report only principles that explain a material observed risk. Do not manufacture findings, turn preferences into defects, or print a principle-by-principle checklist. A review may find no relevant violation.

For tests, use java-testing-style. This skill must not override its rules for test naming, mocking style, unit versus integration boundaries, assertions, layout, or verification scope.
For readable Java naming, guard clauses, Optional, factories, utilities, and test-only production code, use java-readable-code.
For domain-sensitive behavior, identifiers, persistence shape, or invariants, use java-domain-clarification before proposing or coding changes when rules are unclear.
Use java-clean-architecture and java-ddd-architecture only when project instructions explicitly state those architectures; do not move code across such boundaries as incidental cleanup.