Architecture Smell Detection
Architectural Anti-pattern and Smell Identification · Also known as: design smell detection, architectural debt analysis, system quality assessment
Architecture smells are recurring patterns in system structure that indicate potential design problems. Introduced by García et al. (2009), these patterns signal violations of architectural principles (modularity, independence, abstraction) at system scale. Detection combines code metrics, dependency analysis, and pattern recognition to identify smells early, guiding refactoring and architectural improvements.
Read the full method
Sign in with a free account to read this section.
Method map
The neighbourhood of related methods — select a node to explore.
When to use it
Apply architecture smell detection during periodic architecture reviews, before major refactoring, or when troubleshooting development velocity degradation. Use to identify components whose growing complexity justifies extraction or modularization. Particularly valuable when transitioning from monolithic to microservice architectures, identifying natural service boundaries.
Strengths & limitations
- Detects system-level design issues often invisible to code-level analysis
- Identifies components eligible for modularization or service extraction
- Automated analysis scales to large systems; detects patterns across millions of lines
- Guides architectural discussions with objective, quantifiable evidence
- Architecture smell detection lacks the maturity and tool support of code smell analysis
- Context-dependent: some smells are false positives (intentional designs); judgement required
- Dependency extraction from code is imperfect; language-specific conventions affect detection accuracy
- No universally agreed-upon catalog of architectural smells; definitions vary across literature
Frequently asked
What are the most common architecture smells?
Common smells include: Hub-like Dependency (one component with excessive fan-in/fan-out), Cyclic Dependencies (circular imports between modules), Broken Encapsulation (internal details exposed), and Dense Structure (tightly-coupled clusters). Other examples: Scattered Responsibility (concern spread across many modules), Feature Envy (component depending heavily on internals of others).
How do I distinguish architecture smells from legitimate design patterns?
Context matters enormously. A pattern in one system is a smell in another. Use patterns when they serve a clear purpose and provide benefits (e.g., facade pattern hiding complexity). Smells arise when design creates coupling or complexity without corresponding benefit. If you cannot articulate why a pattern exists, suspect a smell.
How can I remove architecture smells without disrupting ongoing development?
Prioritize high-impact smells. Plan refactoring incrementally: 1) introduce abstraction layer, 2) gradually migrate dependencies, 3) remove old dependency after migration complete. Pair architectural improvements with feature development: assign new features to refactored modules. Use branch-by-abstraction pattern to refactor behind feature flags.
Are all architecture smells harmful?
No. Some smells are intentional trade-offs for performance, simplicity, or business constraints. For example, tight coupling between performance-critical modules may be justified. Evaluate smells in context: does the smell enable legitimate requirements? If yes, document the rationale. If no, fix it.
Sources
- Fowler, M. (2018). Code smell. Martin Fowler's Website. link ↗
- Garcia, J., Popescu, D., Edwards, G., & Medvidovic, N. (2009). Identifying architectural bad smells. In Proceedings of the 2009 IEEE/IFIP Conference on Software Architecture (pp. 141–150). DOI: 10.1109/csmr.2009.59 ↗
- Lanza, M., & Marinescu, R. (2005). Object-Oriented Metrics in Practice. Springer. link ↗
How to cite this page
ScholarGate. (2026, June 3). Architectural Anti-pattern and Smell Identification. ScholarGate. https://scholargate.app/en/software-engineering/architecture-smell-detection
Which method?
Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.
- Defect Prediction ModelSoftware Engineering↔ compare
- Software Complexity MetricsSoftware Engineering↔ compare
- Static Code AnalysisSoftware Engineering↔ compare
- Technical Debt MeasurementSoftware Engineering↔ compare