Joe's
Digital Garden

22U092317

Reflections on "Frameworks Harm Maintenance"

Berkes wrote an excellent piece titled "Using a Framework will harm the maintenance of your software1" which is receiving much discussion, largely due to it's inflammatory title. But Berkes buries the lead. The real core truth in the article is this: that frameworks provide little benefit when composing the domain layer and should be decoupled from the core domain.

Essentially, kitchen-sink frameworks (Rails, Laraval, etc.) lack expressiveness to really model the domain itself. In order to do so you must fall back to a general purpose programming language and build an architecture that matches the processes, flows, concepts and language of the domain. A framework is not a substitute for developers knowing how to design solid architecture. The result is that the core of your business logic will contain few concepts from the framework, and this is good.

By decoupling the domain layer from the framework you invert the flow. The domain defines the interfaces for the business logic that the framework consumes and passes into the domain. The benefit for this is when the framework du jour is replaced by the latest hotness, or the latest update to your framework introduces major backward incompatibilities -- or your application outgrows being a straightforward HTTP application and becomes hexagonal and needs to interface with an event-bus or a cli things will be much less painful.

You are still getting the benefits of the framework in this architecture. HTTP, request validation, marshalling json responses, authentication, authorization, and interfacing with persistence layers (file systems, databases etc.) are all cleanly separated from the business logic which should be agnostic about these operational concerns.

Many a developer, even experience developers, make the mistake of thinking the persistence layer, that is the database is the domain. Too frequently this results in the business logic being smeared carelessly around the layers of the framework instead of being consolidated into one place. The technical debt of collecting those bits of domain together will come due when the first major framework rewrite occurs.

A well written domain layer is portable and will go on to outlive the hot frameworks of the day or possibly even the language it was written in.

External References

  1. Kessels, Ber. Using a Framework will harm the maintenance of your software <https://berk.es/2022/09/06/frameworks-harm-maintenance/>. Retrieved 2022-10-12.

Linked References