Code Onion

The code of an application is like an onion, which is why it may make you cry sometimes. It looks like this:


The core

This is the code domain where unit test coverage is the highest, hence refactoring is free. This code is as clean as it can be. This is the comfortable place where everybody wants to work in. Thanks to high test coverage, the feedback loop is short and fast so morale and courage are high when it comes to touch anything in this area.

The borders

This is where most of the compromises happen. Dictated by the use of frameworks or application containers, code becomes invaded with inane accessors, class names end up hard-coded in configuration files, out-of-code indirections (like JNDI based look-ups) weaken the edifice. Unit and integration tests help building reasonable confidence but some refactoring can induce issues that can only be detected when deploying in a target container. This slow and long feedback loop reduces the opportunities to make things better in this area.

The wilderness

This is the outside world, where the rift between the world of code and the harsh reality of life resides. Databases inhabit this place and provide great services but they mismatch with objects. The network is there too, always happy to teach your application pesky lessons about latency, droped packets or broken pipes. Worst of all, users (yes, Tron, they exist) have invaded this area: from there they will constantly find creative ways to abuse your innocent code.

Tensions exist at the touch surfaces between these three layers, resulting in incongruous invasions of concerns and perversions of one layer into another. Ideally these layers would not exist: we would not need frameworks to bridge the world of pure code with the real world. In the meantime this dream comes true, we will have to keep dealing with the code onion and, every now and then, shed a tear on less than ideal code.