[dkarl]

> But web applications are not just pipelines of isolated tools. They are full of shared assumptions: request shapes, validation boundaries, session handling, rendering, routing, serialization, deployment targets.

Some of those things are specific to web applications. Others are not. It's fine for web-specific logic to be tied to all of the shared assumptions of a web framework, but application logic should not be. As the architecture evolves, the application logic may need to be run in other architectural contexts: as a message consumer, inside an orchestration framework, etc.

That's one of the most painful things about PHP. Entire businesses get built around business logic in PHP backends, and then when you need to execute that logic in a different architectural context, every line of it has to be rewritten, because it's too much work to extricate it from the context of serving web requests.

If you are designing your framework to contain application logic, then it should look ahead to the possibility of that logic being used in a different architectural context. It should facilitate and encourage writing application logic that is agnostic of the web context. Otherwise you're encouraging people to repeat the mistake of PHP all over again.

[jjice]

If you work in a legacy PHP codebase, it's inevitable that you'll see $_GET in the middle of what you thought could be isolated business logic. The coupling that was done in my experience old PHP codebases is awful.

I guess I can't blame PHP because it comes down to the devs to enforce decent boundaries, but I think PHP makes it easier than others to do so.

PHP is so much better now, but if you're writing PHP, there's a very good chance you're not working with that new, clean PHP.