When Duplication Is Better Than Abstraction

The Angular Principle Most Teams Learn Too Late

We Learn “Don’t Repeat Yourself” Very Early

One of the first software engineering principles developers learn is:

Don’t Repeat Yourself (DRY).

It’s good advice.

Until it isn’t.

Many Angular applications become difficult to maintain not because they contain duplicate code…

But because developers removed duplication too early.

**Not a Member? Read for FREE here.**

The Problem Starts With Good Intentions

Imagine two Angular features.

Customer Feature
• CustomerCardComponent

Order Feature
• OrderCardComponent

Both components look similar.

A developer thinks:

“These are almost identical.”

Let’s create:

BaseCardComponent

Problem solved.

Or so it seems.

Similar Doesn’t Mean The Same

The Customer card displays:

• Customer Name
• Membership
• Loyalty Points

The Order card displays:

• Order Number
• Shipping Status
• Payment State

Today they share 90% of the UI.

Six months later…

They don’t.

The Generic Component Begins To Grow

Now Customer needs:

showMembershipBadge

Orders don’t.

Orders need:

showTrackingStatus

Customers don’t.

Soon your generic component has:

• 24 Inputs
• 16 Outputs
• 12 Conditional Templates
• Multiple Feature Flags

The component became reusable.

But it stopped being understandable.

Every Abstraction Has A Cost

Abstractions reduce duplication.

But they increase coupling.

Now changing one component risks breaking five features.

Instead of maintaining two small components…

You’re maintaining one enormous generic framework.

Duplication Isn’t Always Bad

Some duplication is intentional.

It creates:

• Clear ownership
• Independent evolution
• Simpler code
• Easier testing
• Faster onboarding

Sometimes two similar components should remain separate.

Because their futures are different.

Optimize For Tomorrow

Don’t ask:

Can these be merged today?

Ask:

Will these evolve together next year?

Architecture is about future change.

Not today’s similarities.

Angular Makes Reuse Easy

Angular encourages:

• Shared Components
• Directives
• Services
• Utilities
• Libraries

That’s great.

But every abstraction should solve an actual problem.

Not an imagined future problem.

The Rule Of Three

One practical guideline many experienced engineers follow:

The first implementation teaches you.

The second confirms a pattern.

The third justifies an abstraction.

If you’ve only seen the problem once…

You’re probably designing too early.

Think About Business Capabilities

Customer management.

Order management.

Billing.

Reports.

They may look similar.

They often evolve independently.

Business boundaries matter more than visual similarity.

A Practical Checklist

Before creating a reusable abstraction, ask:

• Are these solving the same business problem?
• Will they change together?
• Do they share behavior or only appearance?
• Is duplication actually hurting us today?

If the answer is no…

Keep them separate.

Final Thoughts

Duplication isn’t the enemy.

Unnecessary coupling is.

Great Angular architects don’t remove every duplicate line of code.

They remove the duplication that truly matters.

Sometimes the simplest architecture contains two similar components.

Because simple duplication is often easier to understand than a perfect abstraction.

The best Angular applications optimize for clarity, not cleverness.

And sometimes…

The clearest solution is writing the same code twice.

[embed]Stop Putting Business Logic Inside Components: The Architecture Mistake That Slows Every Angular… Every Angular Project Starts the Same Waymedium.com

Connect with Me

If you enjoyed this post and would like to stay updated with more content like this, feel free to connect with me on social media:

• Twitter : Follow me on Twitter for quick tips and updates.
• LinkedIn : Connect with me on LinkedIn
• YouTube : Subscribe to my YouTube Channel for video tutorials and live coding sessions.
• Dev.to : Follow me on Dev.to where I share more technical articles and insights.
• WhatsApp : Join my WhatsApp group to get instant notifications and chat about the latest in tech

Email: Email me on dipaksahirav@gmail.com for any questions, collaborations, or just to say hi!

I appreciate your support and look forward to connecting with you!