Anemic Domain Model
Domain objects that are just data containers, with business logic scattered elsewhere.
Domain objects that are just data containers, with business logic scattered elsewhere.
Comprehensive guide to Big Ball of Mud in software architecture
Obsolete code that won't die, accumulating to form unmaintainable legacy.
Too much communication between objects, causing latency and tight coupling.
Duplicating code instead of extracting shared functionality, violating DRY principle.
Microservices independent in deployment but tightly coupled in design.
Tests that pass sometimes, fail other times due to timing, randomness, or shared state.
One class doing too much with many responsibilities, violating single responsibility principle.
Using one familiar solution for every problem, even when better alternatives exist.
Adding abstraction layers beyond what's needed, reducing clarity.
Using design patterns everywhere, even when simple solutions work better.
Optimizing code before understanding where bottlenecks actually are.
Multiple services accessing one shared database, creating tight coupling.
TL;DR
Complex, tangled control flow without clear structure, making code hard to understand and modify.