Strategic architecture, tactical design, and testable code principles (SOLID, Clean Architecture, Design Patterns, Testable Design)
97
97%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Classes used together should be in the same component. Classes not used together should be in separate components. Forcing a client to depend on things it doesn't use creates unnecessary coupling.
Incorrect (monolithic utility package):
// utils/src/main/java/com/app/utils/
├── StringUtils.java
├── DateUtils.java
├── FileUtils.java
├── HttpUtils.java
├── CryptoUtils.java
├── ImageUtils.java // Depends on ImageMagick
└── PdfUtils.java // Depends on iText
// pom.xml for utils module
<dependencies>
<dependency>imagemagick</dependency> <!-- 50MB -->
<dependency>itext-pdf</dependency> <!-- 20MB -->
<dependency>bouncycastle</dependency> <!-- 10MB -->
</dependencies>
// A service that only needs StringUtils
// must now depend on all 80MB of transitive dependenciesCorrect (split by usage pattern):
// string-utils/
├── StringUtils.java
└── pom.xml // No heavy dependencies
// date-utils/
├── DateUtils.java
└── pom.xml
// image-processing/
├── ImageUtils.java
├── ImageResizer.java
└── pom.xml // ImageMagick dependency only here
// pdf-generation/
├── PdfUtils.java
├── PdfBuilder.java
└── pom.xml // iText dependency only here
// crypto/
├── CryptoUtils.java
├── HashingService.java
└── pom.xml // BouncyCastle dependency only here
// Services import only what they need
// order-service depends on string-utils, date-utils (2MB)
// report-service depends on string-utils, pdf-generation (22MB)Benefits:
Reference: Clean Architecture - Common Reuse Principle
clean-architecture
evals
references
design-patterns
solid-principles
testable-design