Three convictions
I keep returning
to.

The single largest source of architectural decay I've seen is the slow leak of framework concerns into the domain. A NestJS decorator here, a Drizzle import there, a Kafka envelope baked into a value object — each one looks like a small convenience at the time. A year later, the domain layer doesn't compile without the framework, can't be tested without booting the infrastructure, and can't be reasoned about without remembering which version of which adapter is in scope.

So I keep the domain pure. Pure TypeScript. No NestJS, no ORM, no broker, no provider SDK in the import graph. Aggregates, value objects, domain events, and repository interfaces — that's it. The application layer composes use-cases against those interfaces. The infrastructure layer implements them with whatever the world happens to be running this year.

The cost is more files, more interfaces, and the discipline to refuse the convenient import. The win is that every adapter — the database, the queue, the LLM provider, the search engine — becomes replaceable without touching the part of the code that encodes the business.

Most “multi-tenant” systems are actually single-tenant systems with a WHERE clause. The application code filters by tenant; the database trusts the application. The first time someone forgets the filter, two tenants see each other.

Real multi-tenancy is enforced at three layers, simultaneously. At the domain, tenant identity is a first-class invariant of every aggregate. At the database, row-level security is on; service roles do not have BYPASSRLS; every transaction sets app.current_tenant_id first. At the transport, every event envelope and every API request carries a tenant header — the JWT claim, the path parameter, and the envelope header all agree before the request reaches a handler.

The cost is plumbing in three places. The win is that “multi-tenant data leak” stops being a class of bug your system can have.

There's a particular kind of architecture document that reads beautifully and is entirely wrong. It's wrong because the author hasn't built anything in the constraints they're prescribing for years, and the constraints they remember are no longer the constraints that exist.

The cure isn't more diagrams. The cure is shipping. Not as a side hobby — as a structural part of the architecture practice. I keep the Ghasi suite running for this reason: five product platforms with real domain layers, real outboxes, real CI gates, real on-call. It's how I keep my hands close enough to the code that when I'm at the Architecture Review Board recommending an approach, I'm recommending it from inside the constraint, not above it.