A Theory of Software Architecture

[Uncle Bob is clear](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...) that the inside circles must not know about the outside world.

That is, your business logic is not allowed to know what a DB operation is, nor should it do any DB operations behind the scenes.

> Frameworks and Drivers.

> The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

> This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

This discussion has gone on for a long time, e.g. see the back-and-forth around https://dhh.dk/2014/test-induced-design-damage.html after Weirich demonstrated what sort of thing is required to use the Hexagonal Architecture with Rails.

I believe that if your system is sufficiently complex, you'll start to see the benefits of a more structured architecture, but it's a net drag on productivity for small projects. These days perhaps you chop your monolith into microservices before reaching the ROI point for Clean/Hexagonal?

I could believe that a "framework-first" architecture is more productive while you have <100kloc. Or maybe it's <10kloc, I don't know. I'm certainly seeing the architectural strain with a Django-first architecture in the current 150kloc monolith I'm working on, and chopping into a few services makes sense there for other reasons, so it might obviate the need for a bigger refactor onto Clean/Hexagonal.

These sorts of things are always better discussed in terms of specific cases instead of generalities, but I think one of the key parts of good software engineering is factoring the requirements into the simplest design possible.

And even when time or other considerations prohibit creating an extensive design ahead of time, practicing a few well-chosen heuristics like "use composition", "keep functions and methods short", "use clearly defined and consistent terminology in your abstractions" can go a long way to making code less unruly and easier and cheaper to refactor down the road.