DEV Community: Amirsaeed Sadeghi Komjani

Why Do So Many Teams Fail at Testing?

Amirsaeed Sadeghi Komjani — Fri, 12 Dec 2025 10:12:13 +0000

Why Do So Many Teams Fail at Testing?

Almost every team starts with the same optimism.

At the beginning:

TDD is declared “the right way”
“Code without tests equals bugs” becomes a mantra
Frameworks, runners, and pipelines are set up with care

Everything looks mature and professional.

Then a few months pass.

Reality slowly shows up.

Tests become painfully slow.

A small change breaks dozens of unrelated tests.

No one has time to refactor the test suite.

Test debt grows quietly.

Deadlines arrive, and management pressure increases: “Ship first, fix later.”

At that point, tests stop being a safety net.

They turn into a burden.

Teams either abandon them entirely or keep them just to satisfy metrics.

Coverage numbers look fine, but confidence is gone.

The Uncomfortable Truth About TDD

Here is the controversial part.

Classic TDD does not always work.

Many teams adopt it with enthusiasm, but without the conditions it actually requires.

Velocity drops.

Deadlines get tighter.

And eventually, even the important tests stop being written.

TDD works best when:

The domain is well understood
Uncertainty is low
Discipline is consistently high
The team treats tests as first-class code

Most real-world projects do not meet these conditions.

Requirements change.

Architecture evolves.

Time is limited.

In those environments, strict TDD often creates more friction than value.

The Real Problem Is Not Testing — It’s How We Think About It

Tests are often treated as a ritual, not as software.

But tests are software.

They have architecture.

They need maintenance.

They create coupling.

They accumulate debt.

High coverage without meaningful assertions creates a false sense of security.

A thousand fragile tests are worse than ten reliable ones.

If a test does not protect a business rule, a critical workflow, or a risky integration,

its value should be questioned.

A More Pragmatic Approach

In practice, many teams succeed with a different mindset:

Design for testability first, not test-first by default
Write tests after the design is clear enough to be stable
Focus on boundaries: core logic, integrations, critical paths
Accept that not everything deserves a test
Measure confidence, not coverage

A mix of test-after and thoughtful design often produces more resilient systems than rigid dogma.

Final Thought

Testing is not about purity.

It is about trust.

If your test suite slows you down, breaks constantly, or no longer gives confidence,

the problem is not a lack of discipline.

It is a lack of architectural thinking applied to tests.

Sometimes, fewer tests — designed better — protect a system far more than perfect coverage ever could.

What has been your experience?

Does TDD genuinely help your team, or only under very specific conditions?

When deadlines hit, are tests part of the Definition of Done — or the first thing sacrificed?

From Framework Lock-in to Building Our Own ORM

Amirsaeed Sadeghi Komjani — Sat, 08 Nov 2025 10:30:41 +0000

Why we decided to build a custom ORM in a real-world project

The Problem

In one of our enterprise projects, the core requirement was clear: the
Core had to be fully independent from any framework --- so that future
migrations (to another framework or even another programming language)
would not require rewriting the business logic.
That requirement forced us to build the Core from scratch, without any
framework dependencies. The biggest challenge? Designing a
framework-agnostic Data Access Layer, which naturally led us to
build our own QueryBuilder/ORM.

Architectural Goals

Decouple domain logic from infrastructure and framework layers
Enable technology migration without rewriting domain code
Achieve full unit-testability without a real database
Gain fine-grained control over query generation and execution

Why existing ORMs didn't fit

Framework-Independent Data Layer -- Most popular ORMs are deeply tied to the lifecycle and conventions of their host framework.
Unit Testing without a real DB -- We needed to test repositories and queries with in-memory fakes.
Modular Clauses -- Each clause had to be composable and replaceable without touching the Core.
Precise Execution Control -- We required control over query batching, timing, and transaction handling.

When "build" makes more sense than "buy"

Domain requirements impose contracts that off-the-shelf ORMs can't model cleanly.
Long-term architectural stability and Core independence outweigh early speed.
The team has enough technical maturity and resources to maintain a custom data layer.
Migration cost and framework lock-in risk are expected to be high across the product's lifespan.

If these conditions aren't met, adopting a mature ORM is wiser.
Reinventing the wheel only makes sense when the wheel you need doesn't
exist.

Design Foundations

Fluent Interface -- A clean, chainable API for query construction
Clause Strategy + Factory -- Each clause implemented as a strategy; a factory orchestrates their composition
Query Context -- Carries state, bindings, and execution metadata
Collection Integration -- Returns results as a collection object supporting map, filter, paginate, and metadata
Ports & Adapters --
- Ports: Repository and QueryService as Core contracts
- Adapters: Database drivers (PDO, MySQL, PostgreSQL) and in-memory adapters for testing
Execution Pipeline -- Staged SQL building, parameter binding, secure execution, and mapping to domain models
Error Mapping -- Translates low-level DB errors into application-level exceptions

Keys to Testability

In-Memory Driver -- Executes clauses in memory for unit tests
Contract Tests -- Guarantee adapter compliance with Core interfaces
Deterministic Hydration -- Predictable mapping from raw data to domain models
Boundary Tests -- Validate that infrastructure concerns never leak into the domain

Performance and Optimization

Lazy vs. Eager Execution -- Build queries lazily, execute explicitly at defined boundaries
Batching -- Combine operations to reduce round-trips
Index-Aware Hints -- Inject DB-specific execution hints without leaking them into Core logic
Metrics Hooks -- Measure runtime performance, record counts, and detect N+1 issues

Transactions and Concurrency

Unit of Work (optional) -- Track and commit grouped changes atomically
Explicit Transactions -- Provide clear APIs for begin/commit/rollback at the adapter layer
Idempotency and Retries -- Built-in hooks for retrying critical operations safely

Pitfalls and Anti-patterns

Reinventing Active Record -- Mixing domain models with DB operations defeats independence
Infrastructure Leakage -- No low-level types or exceptions should cross Core boundaries
Low-level APIs inside Core -- The Core should talk through domain contracts, not SQL or clauses
Ignoring Migration Paths -- Always design for adapter and database version evolution

Comparison Snapshot

Eloquent: Excellent developer experience within Laravel, but tightly coupled to it
Doctrine: Highly flexible and decoupled, but heavy and complex
Custom ORM (ours): Tailored to exact architectural needs, at the cost of maintenance responsibility

Outcome

A framework-agnostic Core, portable across frameworks or even languages
Strong testability without relying on a physical database
Full control over query generation and execution paths
Greater architectural transparency and deeper engineering insight within the team

When not to take this path

The project is short-lived or framework lock-in is an acceptable risk
The team is small and can't maintain a custom data layer
Existing ORMs already meet all functional and architectural requirements

Conclusion

Building a custom ORM is both a technical and economic decision --- not
a vanity project.
If Core independence, offline testability, and precise control over data
access are your first-order priorities and your team can sustain the
maintenance cost, then this path is worth it.
Otherwise, rely on proven ORMs and keep your focus on the domain.

Framework Lock-In: Are you building a product—or just a framework extension?

Amirsaeed Sadeghi Komjani — Tue, 04 Nov 2025 21:36:33 +0000

Ever looked at code that feels more like a framework demo than a real product?

Many teams proudly say: “We’ve built an independent product.”

But when you dig deeper, you realize everything — from routing to authentication — is tightly bound to the framework.

Why is this a problem?

In that scenario, your product has no independent identity.

If the framework gets deprecated tomorrow or the team shifts direction, you’ll end up rewriting everything from scratch.

That’s the danger of Framework Lock-In.

The trade-off

On the flip side, some teams intentionally give up freedom for development speed and community support.

Fair enough… but is that truly a strategy, or just convenience disguised as one?

What often gets forgotten

A real product should have its own architectural identity.

A framework should remain a tool, not the thing that defines your product.

The uncomfortable truth: many so-called “products” are really just framework extensions.

Question

Would your product survive without the framework,

or is it just a plug-in living on top of it?

What do you think?

Have you ever refactored a system that was too tied to its framework?

Why is the line between juniors and seniors so often misunderstood?

Amirsaeed Sadeghi Komjani — Sat, 01 Nov 2025 14:01:58 +0000

In simpler CRUD-based projects, complex architecture quickly turns into technical debt.

Here, developers with a pragmatic, delivery-focused approach (often juniors) tend to be more effective — because business reality values simplicity and speed.

But once a project grows beyond CRUD into service-based or domain-heavy complexity, that’s where seniors show their real value.

The ability to define clear context boundaries, design proper abstractions, and think in terms of scalability and maintainability isn’t something you gain just by writing code for years.

The Real Difference

The difference between a junior and a senior is not about years of experience.

It’s about maturity — in architecture, long-term maintainability, system evolution, and even teamwork and collaboration.

I’ve seen people with 3–4 years of experience act more mature in architecture and team interaction than someone who’s been coding for a decade.

That’s why, instead of counting years on a résumé, we should assess engineering maturity.

Question for you

Have you seen juniors shine in CRUD projects, or seniors saving the day in complex systems?

Let’s discuss

Why Most Developers Misunderstand Clean Architecture

Amirsaeed Sadeghi Komjani — Mon, 20 Oct 2025 10:37:52 +0000

For many, Clean Architecture is just a checklist:

A controller layer
A service layer
A repository for the database

And they think they're done.
But that's only the surface.

Common Mistakes I've Observed

Misunderstanding dependency inversion
Core classes still depend on the database or framework, while the rule
says everything should depend on business logic.

Ignoring context
Developers add ten layers for a simple CRUD app --- resulting in
over-engineering and unnecessary ceremony.

Forgetting business goals
Teams build architecture for engineering ego, not for solving real
problems.

What Real Clean Architecture Looks Like

The core runs even without a database or framework.
Tests execute fast, directly on the domain logic.
Switching frameworks or databases doesn't break the system.

From my experience, the cleanest projects had the fewest layers, but
applied the Dependency Rule and DIP correctly.

Question

Have you seen teams add complexity in the name of Clean Architecture?
Share your experience below.

Did you know your database schema might be leaking through error messages and stack traces?

Amirsaeed Sadeghi Komjani — Sat, 13 Sep 2025 08:08:08 +0000

AI is now smart enough to reconstruct your database from what looks like harmless errors:

SQL errors (constraint violations, duplicate entries)
ORM/Model exceptions (table names, class names, line numbers)
NoSQL hints (like MongoDB’s “document not found” or “index violation”)

Why is this dangerous?

Attackers can gradually infer your schema:

SQL → table names, keys, relationships
NoSQL → collection names, document structures, indexes

Insight

Not all databases leak the same way:

Relational DBs often reveal too much detail.
NoSQL may leak less by default, but verbose logging or misconfiguration changes the game.

What can you do?

Never expose raw errors in production.
Use generic error handling.
Regularly audit your API responses.

What about you?

Have you ever seen a “simple” DB error reveal way too much?
If you had to choose: SQL with verbose errors or NoSQL with misconfig risks — which one feels safer to you, and why?

Your API Security Assumptions Are Outdated: AI Isn’t Just a User — It’s an Attacker

Amirsaeed Sadeghi Komjani — Tue, 02 Sep 2025 07:31:50 +0000

AI isn’t just a user — it can be an attacker.

Most teams still think securing an API means:

Using JWT
Enforcing HTTPS
Applying Rate Limiting

That used to be enough.

But today’s reality is different:

AI is reading and analyzing your responses.

Unlike human users, AI can:

Process millions of API responses
Extract patterns from error messages
Reverse-engineer your system faster than any human hacker

Real-World Vulnerabilities

Here’s how your API might already be leaking knowledge:

Raw stack traces → Reveal your framework and version → AI maps it to known CVEs in seconds.
Exposed SQL queries → Reveal your schema and business logic → Free blueprint for attackers.
Detailed validation errors → Help AI learn your internal rules and edge cases.

📉 The Result?

You’re handing over your system’s architecture to an intelligent attacker — for free.

🛡 Practical Steps to Protect Your API

Obfuscation

Return generic error codes/messages — not full details.
Response Layer

Sanitize and filter every outgoing response.
AI-aware Security

Assume your API is consumed by a learning model, not just a user.

💡 My Take

Once we shifted our mindset from "protecting data" to "protecting knowledge",

many risks simply disappeared.

Your Turn

Do you think AI is becoming:

a helper for security?
or the next big threat?

Let’s discuss in the comments 👇

👉 Follow me for more insights on Software Architecture + Security in the AI Era

Why Design Patterns Often Fail in Real Projects

Amirsaeed Sadeghi Komjani — Mon, 25 Aug 2025 10:45:55 +0000

📉 Honestly, I’ve seen it many times: instead of helping, Design Patterns end up making projects worse.

Common reasons why they fail

Copied directly from books/tutorials without understanding the why and when.
Forcing every problem into a Pattern → pure over-engineering.
Team members interpret patterns differently → inconsistent, bloated code.
Architecture evolves, but rigid implementations stay stuck.

💡 How to make them work (from a CTO’s perspective)

A pattern is a tool, not the goal. Use it only when it solves a repeatable problem.
Align the chosen pattern with the architecture vision & product strategy, not just personal taste.
Make sure the whole team understands why this pattern was picked — otherwise, failure is guaranteed.
Keep the architecture flexible and refactor-friendly.

👉 My take? The most successful patterns I’ve seen were the ones that became a shared language for the team — not a handcuff.

Your turn: Have you seen a Design Pattern cause more pain than value?

Why Most Refactors Fail — And How to Fix Them

Amirsaeed Sadeghi Komjani — Sun, 17 Aug 2025 08:05:37 +0000

“We should refactor the whole thing…”

I've heard this line more times than I can count — and honestly, most of those refactors failed.

Not because refactoring is a bad idea. But because they were done wrong.

📉 Why They Fail

Here are the top reasons I’ve seen (and experienced):

No clear target architecture

“We just want it cleaner” is not a plan.
Lack of test coverage

If you don’t have a safety net, every change is a risk.
Big-bang rewrites

Trying to change everything at once = chaos.
Team misalignment

If everyone has a different definition of “clean,” good luck.

✅ How to Do It Right

If you want your refactor to succeed, start with these:

Define the end goal

What will the architecture look like after refactoring?
Refactor incrementally

Small, focused changes are easier to test, review, and roll back.
Write tests first

Ensure you’re not breaking things while cleaning things up.
Align the team on standards

Agree on patterns, formatting, naming — everything.

💡 My Take

The best refactors I’ve seen had these 3 things:

A clear vision
A solid test suite
A well-communicated plan

Refactoring without those? You’re just rewriting code and hoping for the best.

🙋 Your Turn

Have you ever done a big refactor?

Was it painful or satisfying?
Did you have the plan and tests?
Or was it more like “rip it out and hope”?

Let’s share some refactor war stories in the comments. 👇

Repository Layer: Decoration or Real Architecture?

Amirsaeed Sadeghi Komjani — Fri, 15 Aug 2025 17:17:02 +0000

Many developers add a Repository Layer to make their projects look cleaner and more professional.

But in reality, if all repositories are silently coupled to a single driver like Laravel Eloquent, this layer becomes decorative and useless.

In this post, I’ll explain why that happens, the architectural risks behind it, and how to design a Repository Layer that actually delivers on its promise.

Problem

The issue surfaces when you need to switch databases or introduce a new driver.

Instead of swapping drivers smoothly, you’re forced into a major refactor because your Repository Layer is tightly bound to one specific ORM or database driver.

The Real Purpose of the Repository Layer

A well-designed Repository Layer should:

Allow replacing or adding multiple drivers without touching your services or controllers.
Keep your application multi-driver and even multi-tenant ready.

When implemented correctly, it becomes the abstraction boundary between your domain logic and your data sources — not just an extra file to look “professional.”

How to Fix It — Adapter Pattern to the Rescue

To truly decouple your dependencies:

Define Repository Interfaces in your domain layer.
Create Adapter Classes that translate interface methods into driver-specific implementations.
Use Dependency Injection so your services/controllers depend on the interface, not the concrete driver.

Example in Laravel/PHP:

interface UserRepositoryInterface {
    public function findByEmail(string $email);
}

class EloquentUserRepository implements UserRepositoryInterface {
    public function findByEmail(string $email) {
        return User::where('email', $email)->first();
    }
}

Now, swapping to another driver (e.g., MongoDB) means creating a new adapter without touching the rest of your codebase.

Key Question for You

How do you implement your Repository Layer?
Do you leverage the Adapter Pattern to truly decouple your dependencies, or is your layer just decorative?

Conclusion

A Repository Layer is not just for aesthetics — it’s a key architectural tool for flexibility and scalability.
When paired with the Adapter Pattern, it gives you the freedom to change persistence layers with minimal effort.

💬 Have you ever had to refactor a whole project just to change the database driver? Share your experience in the comments!