Should we use a framework?

Written by Matthias Noback / Original link on Feb. 16, 2021

Since I've been writing a lot about decoupled application development it made sense that one of my readers asked the following question: "Why should we use a framework?" The quick answer is: because you need it. A summary of the reasons:

So, yes, you/we need a framework. At the same time you may want to write framework-decoupled code whenever possible.

Here's a summary of the reasons. If all of your code is coupled to the framework:

Pushing for a big and strong core of decoupled code, that isn't tied to the database technology, or a particular web framework, will give you a lot of freedom, and prevents all of the above problems. How to write decoupled code? There's no need to reinvent the wheel there either. You can rely on a catalog of design patterns, like:

None of these classes will use framework-specific things like:

For me good rules of thumb to test the "decoupledness" of my business logic are:

  1. Can I migrate this application from a web to a CLI application without touching any of the core classes?
  2. Can I instantiate all the classes in the core of my application without preparing some special context or setting up external services?
  3. Can I migrate this application from an SQL database to a document database without touching any of the core classes?

1 and 2 should be unconditionally true, 3 allows some room for coupling due to the age-old problem of mapping entities to their stored format. For instance, you can have some mapping logic in your entity (i.e. instructions for your ORM on how to save the entities). But at least there shouldn't be any service dependencies that are specific to your choice of persistence, e.g. you can't inject an EntityManagerInterface or use a QueryBuilder anywhere in your code classes. Also, calling methods should never trigger actual calls to a database, even if it's an Sqlite one.

If you do all of this, your framework will be like a layer wrapped around your decoupled core:


This layer contains all the technical stuff. This is where you find the acronyms: SQL, ORM, AMQP, HTTP, and so on. This is where we shouldn't do everything on our own. We leverage the power of many frameworks and libraries that save us from dealing with all the low-level concerns, so we can focus on business logic and user experience.

A framework should help you:

For me, a sufficiently good framework will be one that:

Ideally, a framework also:

Note that these aren't necessities. When limited to the technology layer around your decoupled core, a framework can use all kinds of practices that I consider bad. As long as these practices don't influence the design of the decoupled core, this could be fine. However, it requires some discipline. No cutting corners when it comes to your decoupled core!


« Controlling Smart Lights Using Dumb Switches with Shelly and Home Assistant - Laravel Spark Next is Here »