Frameworks should be Hidden

If your framework is constantly reminding you that it’s there, it’s time to rethink its job. Applications need to be freed from the unnecessary constraints being applied to them. They are not your architecture, and should not be making any architectural decisions for you.

When you’re writing application code, the framework should be completely invisible. It can help bootstrap the application, and possibly help wire services and configuration together, but those services should never see it. They should expect their dependencies to be injected, but how that’s done is none of their concern.

When you start to concretely rely on service or dependency injection containers, deep class hierarchies, and deep directory structures, it becomes easy to build a very deeply-ingrained dependency. Applications that do this tend to become very monolithic and hard to maintain/upgrade.

If you can get away with no framework or even a micro framework, give it a try, and start to look at how you’d organize things without the scaffolds to guide you. Otherwise, ask yourself this: does upgrading your framework require any application or domain-level code changes?

You Might Also Like