The Trap of "Perfect" Architecture: What Building a Shopping Cart Taught Me

Habeeb Abdullahi — Sat, 30 May 2026 22:06:27 +0000

Early in my journey as a software engineer, I became fascinated with software architecture.

I spent hours learning about:

SOLID Principles
Clean Architecture
Hexagonal Architecture
Ports and Adapters
Dependency Inversion

The more I learned, the more I became convinced that every project should be highly decoupled, framework-agnostic, and future-proof.

Then I built a shopping cart application.

And that's when reality taught me a lesson that no book could.

Building It "The Right Way"

Instead of creating a straightforward React application, I decided to apply a strict layered architecture.

My project was structured like this:

UI
│
Controllers
│
Application
│
Domain
│
Adapters
│
Infrastructure

Every responsibility had its own layer.

Every dependency pointed inward.

Every interaction crossed carefully designed boundaries.

At first, I loved it.

The folder structure looked professional.

The separation of concerns looked clean.

The architecture looked impressive.

Then I started building features.

The Architectural Tax

A simple feature change often required updates across multiple layers.

Something that should have taken minutes turned into a journey through several directories and files.

I found myself spending more time maintaining architectural boundaries than solving actual problems.

That's when I realized something important:

Architecture isn't free.

Every layer comes with a cost.

Every abstraction comes with a cost.

Every boundary comes with a cost.

You pay for it with:

More files
More indirection
More cognitive load
More debugging effort
Slower development velocity

The architecture wasn't wrong.

The problem was that the complexity of the architecture was greater than the complexity of the application itself.

Architecture Is a Budget, Not a Rulebook

This realization completely changed how I think about software design.

The question is not:

"Is this architecture clean?"

The better question is:

"What problem is this architecture solving, and is that problem large enough to justify its cost?"

A shopping cart application with a handful of features does not face the same challenges as a large enterprise system.

Treating both projects the same way can actually make the smaller project harder to maintain.

The Framework-Agnostic Illusion

One of my goals was to make the application completely independent of React.

I wanted to be able to swap React for another framework in the future.

In theory, that sounded like great engineering.

In practice, I realized I was optimizing for a scenario that might never happen.

The changes that are almost guaranteed to happen are:

New features
Requirement changes
UI updates
Bug fixes
Refactoring

A complete framework migration is usually much less likely.

Today, I still keep business logic isolated, but I no longer try to abstract every single framework detail away.

What I Prefer Now

My current frontend architecture is much simpler:

Domain

Pure business logic.

No React.

No API calls.

No UI concerns.

Infrastructure

External systems such as:

API clients
Storage
Third-party services

Hooks

State management and orchestration.

The bridge between the domain and the UI.

UI

Presentation components.

Focused on rendering and user interaction.

Nothing more.

This gives me most of the benefits I care about without introducing unnecessary complexity.

The Biggest Lesson

The lesson wasn't that Hexagonal Architecture is bad.

The lesson wasn't that Clean Architecture is wrong.

The lesson was this:

Architecture should solve real problems, not hypothetical ones.

Sometimes adding a boundary is the right decision.

Sometimes removing a boundary is the right decision.

The difficult part is knowing the difference.

And that's not something you learn from reading alone.

You learn it by building software, experiencing the friction, and understanding the trade-offs firsthand.

Final Thoughts

Engineering maturity isn't about applying every design pattern you've learned.

It's about understanding the cost and value of each decision.

The goal isn't perfect architecture.

The goal is reducing the cost of future change.

Build.

Ship.

Learn.

Then simplify.

Have you ever realized you were over-engineering a project? What lesson did it teach you?

JavaScript vs TypeScript? Maybe We’ve Been Asking the Wrong Question.

Habeeb Abdullahi — Thu, 30 Apr 2026 12:23:08 +0000

A lot of developers frame JavaScript vs TypeScript as a debate about which one is better or more professional.

But in real-world systems, that question often misses the real issue.

The difference between good and bad developers is rarely about the language. It is about understanding software design, data flow, and runtime behavior.

Let’s look at a practical example.

Bad TypeScript (Type Safety Without Real Safety)

This is a common pattern

type User = {
  id: string;
  name: string;
  email: string;
};

async function getUser(id: string): Promise<User> {
  const res = await fetch(`/api/user/${id}`);
  return res.json();
}


async function showUser(id) {
  const user = await getUser(id);
  console.log(user.email.toUpperCase())
  }

showUser("123");

What is wrong here

On the surface this looks clean and type safe

But in reality

• The API response is not validated
• The server could return null or incomplete data
• TypeScript is being trusted blindly
• Runtime errors are still possible

This is what happens when TypeScript is used as a replacement for validation instead of a supplement

✅ Better JavaScript (Safer Through Design)

Now compare this approach

function isUser(data) {
  return (
    data &&
    typeof data.id === "string" &&
    typeof data.name === "string" &&
    typeof data.email === "string"
  );
}

async function getUser(id) {
  const res = await fetch(`/api/user/${id}`);
  const data = await res.json();

  if (!isUser(data)) {
    throw new Error("Invalid user data received from API");
  }

  return data;
}

async function showUser(id) {
  try {
    const user = await getUser(id);
    console.log(user.email.toUpperCase());
  } catch (err) {
    console.error("Failed to load user:", err.message);
  }
}
showUser("123");

Why this JavaScript approach can actually be safer

• It validates real runtime data instead of assumptions
• It fails explicitly when something is wrong
• It separates concerns between fetching, validation, and usage
• It scales naturally into schema based systems like Zod or Joi

The real takeaway

TypeScript improves developer experience and static safety.

But:

real world safety comes from architecture, validation, and understanding runtime behavior, not types alone.

You can write unsafe TypeScript and safe JavaScript.

The difference is not the language.

It is the engineering discipline behind it.

If you are serious about frontend engineering, the real question is not:

JavaScript or TypeScript

It is:

Do I understand what actually happens when my code runs?

What’s your take? Does TypeScript make better developers or do fundamentals matter more?

DEV Community: Habeeb Abdullahi