Strategic architecture, tactical design, and testable code principles (SOLID, Clean Architecture, Design Patterns, Testable Design)
71
89%
Does it follow best practices?
Impact
—
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
.tessl-plugin
clean-architecture
references
design-patterns
references
solid-principles
testable-design