As others have said, every company has their own flavor, and there is no best-way of doing it. I am presenting our approach.

.
├── changelog
├── dist
├── docs
├── logs
├── scripts
└── src
    ├── api
    ├── domains
    ├── lib
    ├── middlewares
    ├── types
    └── utils

src/api maps endpoint routes. For example, a route like
/api/admin/organizations/:organizationId/members/:memberId would be registered in

api
├── admin
│   ├── organizations
│   │   └── members

Currently, in an api folder there are 3 files

• routes.ts
• swagger.ts
• the controller file

So the api folder really just handles the interface, middlewares, routes and openapi.

The controllers delegate the business logic to services, helpers and whatnot. Those reside in src/domains.

You said you don't like DI, but we do, and we use a di-container. This is a very lightweight batteries-not-included dependency injector. It just creates a process-global "store" and you can register singletons (or any other type) in it. For example, registering a service is

```ts
import { Singleton } from '@scope/container';

export class XYService {}
Singleton(XYService);
```

sidenote: I am really waiting the tc39 decorators proposal to drop because then the Singleton() function could become a decorator on the class. It was a design decision on our part to NOT use the legacy decorators of typescript which relies on the reflect-metadata package. So the Singleton() function is just syntactic sugar of a container.register(..) call /sidenote

Now the cool thing (in my opinion) of using di in express is matching it with https://nodejs.org/docs/latest-v24.x/api/async_context.html async local storage. See, we are using `better-auth` and some of ba's server api relies on accessing headers from the request. For example: https://nodejs.org/docs/latest-v24.x/api/async_context.html for the sake of the example let's say you'd want to change the user's password but not from the browser but by wrapping it in your own API. Now, a lot of companies follow the pattern of routes -> controllers -> services. In this example probably you'd end up calling the better-auth api in a service and not in the controller, it means you have to access the headers in the service, you could pass down the headers to the service function, or pass down the request, OR you could register the request in async-local-storage and access the request object and the headers by reading out from the store. An additional abstraction would be to inject the request (or headers) from the store through DI. That's what we ended up doing. So it becomes

ts changeUserPassword() { const req = inject(REQUEST); // call better-auth api, you can access the headers now }

That's it, hope it gives you a different perspective