Stop Overengineering in the Name of Clean Architecture

[Lomanu4]

Clean Architecture is a great concept. It’s meant to help you write maintainable, modular, and scalable software.

But too many developers treat it like a religion. They follow it blindly, stuffing projects with unnecessary layers, abstractions, and patterns. All in the name of “clean code.”

Let’s be honest, Clean Architecture is often overused, not because the ideas are bad, but because people overengineer the implementation.

A Quick Joke (That Some Devs Write Unironically)


Here’s an example of multiplying two numbers implemented with an absurd number of patterns:


// overengineered-multiplier.ts

// Interface
interface IMultiplier {
multiply(a: number, b: number): number;
}

// Singleton
class MultiplierService implements IMultiplier {
private static instance: MultiplierService;

private constructor() {}

static getInstance(): MultiplierService {
if (!MultiplierService.instance) {
MultiplierService.instance = new MultiplierService();
}
return MultiplierService.instance;
}

multiply(a: number, b: number): number {
return a * b;
}
}

// Adapter
interface IMultiplierInput {
x: number;
y: number;
}

class InputAdapter {
constructor(private readonly rawInput: [number, number]) {}

adapt(): IMultiplierInput {
return { x: this.rawInput[0], y: this.rawInput[1] };
}
}

// Decorator
class LoggingMultiplierDecorator implements IMultiplier {
constructor(private readonly inner: IMultiplier) {}

multiply(a: number, b: number): number {
console.log(`Logging: Multiplying ${a} * ${b}`);
const result = this.inner.multiply(a, b);
console.log(`Logging: Result is ${result}`);
return result;
}
}

// Proxy
class MultiplierProxy implements IMultiplier {
constructor(private readonly target: IMultiplier) {}

multiply(a: number, b: number): number {
if (typeof a !== 'number' || typeof b !== 'number') {
throw new Error('Invalid input types');
}
return this.target.multiply(a, b);
}
}

// Abstract Factory
interface IMultiplierFactory {
create(): IMultiplier;
}

class RealMultiplierFactory implements IMultiplierFactory {
create(): IMultiplier {
const singleton = MultiplierService.getInstance();
const withLogging = new LoggingMultiplierDecorator(singleton);
const withProxy = new MultiplierProxy(withLogging);
return withProxy;
}
}

// Usage
const rawInput: [number, number] = [6, 9];
const adapted = new InputAdapter(rawInput).adapt();

const factory = new RealMultiplierFactory();
const multiplier = factory.create();

const result = multiplier.multiply(adapted.x, adapted.y);
console.log(`Final Result: ${result}`);

All of this just to calculate 6 * 9. This is what happens when design patterns become cosplay.

The Real Problem: Over-Abstraction


Clean Architecture promotes decoupling. That’s good. But too many devs interpret that as "abstract everything."

Example:


interface IUserRepository {
findById(id: string): Promise<UserDTO>;
}

class UserRepositoryImpl implements IUserRepository {
constructor(private db: PrismaClient) {}

async findById(id: string): Promise<UserDTO> {
return await this.db.user.findUnique({ where: { id } });
}
}

Then you add a use case on top:


class GetUserByIdUseCase {
constructor(private repo: IUserRepository) {}

async execute(id: string): Promise<UserDTO> {
return this.repo.findById(id);
}
}

All of this for one database call. This isn’t clean it’s waste.

Common Overengineering Patterns

1. Interfaces and Implementations for Everything


Blindly creating an interface and a class for every service adds friction without real value.

Use it when:

• You actually have multiple implementations
• You’re building a plugin system or SDK

Don’t use it when:

• You only have one implementation
• You’re doing it "just in case"

2. Use Case Classes for Simple Logic


class CreatePostUseCase {
execute(input: CreatePostDTO): Promise<PostDTO> {
return this.postRepo.create(input);
}
}

This is a one-line call. Wrapping it in a class adds nothing. Use a service or method directly unless business logic really requires separation.

3. DTO Explosion


type Post = { id: string; title: string; content: string };
type CreatePostDTO = { title: string; content: string };
type PostResponseDTO = { id: string; title: string; content: string };

If the structure is the same across layers, reuse the object. You don’t need a new DTO for every transition unless there’s a reason.

4. Domain Models with No Behavior


class User {
constructor(public id: string, public name: string) {}
}

If your "domain entity" is just a data wrapper, it’s not a domain model. Add behavior or don’t abstract.

5. Dependency Injection Overkill


@Module({
providers: [
{ provide: IUserService, useClass: UserServiceImpl },
{ provide: IUserRepository, useClass: UserRepositoryImpl }
]
})

DI containers are great. But if you’re not benefiting from polymorphism or dynamic injection, just instantiate the class.

What You Should Do Instead

• Start simple. Build complexity only when needed.
• Abstract with intent. Not everything needs to be swappable.
• Refactor later. Let the structure grow organically as the app gets more complex.
• Optimize for clarity. Not for pleasing architecture diagrams.

Clean Code Is Not More Code


Good code is:

• Easy to read
• Easy to test
• Easy to change

It’s not defined by how many layers, decorators, or design patterns it uses.

Final Thoughts


Clean Architecture should serve your code, not the other way around.

It’s a tool, not a rulebook. Use it to solve complexity not to create it.

TLDR

Avoid This	Do This Instead
Interface and Impl for everything	Use one class until you actually need two
Use cases for CRUD logic	Use simple services or methods
Separate DTOs for same shapes	Reuse types where possible
DI for everything	Instantiate directly when practical
Layers for layers’ sake	Let structure grow with real needs

Build software, not monuments.

Пожалуйста Авторизируйтесь или Зарегистрируйтесь для просмотра скрытого текста.