In this episode of the No Silver Bullet podcast, we discuss Clean Architecture and whether it's overengineering or a best practice for organizing code.We talk about why the pattern is often controversial, when it makes sense to use it, and how to implement it effectively.We share our experiences using Clean Architecture across different projects and teams, including the common concerns developers have when first seeing it.

Quick takeaways:

• Clean Architecture is most beneficial for complex projects with larger teams - for small teams or simple projects, it can become overengineering.
• Separation of concerns is the core benefit - keeping domain logic separate from implementation details makes code more maintainable.
• It's easy to go too far - using too many interfaces or too many layers without a clear reason creates unnecessary complexity.
• Start simple and evolve your architecture - don't force Clean Architecture from the start if your project doesn't need it yet.
• Understanding the "why" behind the pattern is crucial - blindly following it without understanding leads to poor implementations.

Notes:

• Related patterns:
• The Dependency Inversion Principle: one of SOLID principles.
• Blog post: Introducing Clean Architecture: https://threedots.tech/post/introducing-clean-architecture/
• Blog post: Microservices test architecture: https://threedots.tech/post/microservices-test-architecture/
• Blog post: Repository Pattern in Go: https://threedots.tech/post/repository-pattern-in-go/
• Blog post: Combining DDD, CQRS, and Clean Architecture in Go: https://threedots.tech/post/ddd-cqrs-clean-architecture-combined/ (Mentioned as available)
• Example Go Project: Wild Workouts: https://github.com/ThreeDotsLabs/wild-workouts-go-ddd-example
• go-cleanarch Linter: https://github.com/roblaszczak/go-cleanarch

Full episode notes: https://threedots.tech/episode/is-clean-architecture-overengineering/