Levelization is a simple organizational principle or metric applied to code, first promoted by the great John Lakos in his landmark book "Large Scale Software Design in C++" (if you haven't read it, buy it now and read it, even if you never write in C++). This was experience gained the hard way, on one of the first and largest projects that suffered the results of "modern" "object-oriented" thinking applied to a codebase of tens of millions of lines. The lessons learned however are very general and applicable to code that needn't be in C++ and needn't be very large. Some of the low-level concepts from Lakos' book are summarised on this page of lecture notes, with a little discussion of the high level at this page. You can also read some recommendations for package design.

Levelization assigns a dependence level number to each physical unit (in Java, read "class") of code, organized in a graph (hopefully DAG) of "knowledge". Class A "knows about" or depends on class B if the name of class B occurs anywhere in its definition - in C++ there are various degrees of dependence (inheritance, structural, by pointer, "in name only", or opaque) not all of which are possible in Java. Opaque dependence, where there is no longer any evidence of dependence in the code (illustrated by Lakos in a chapter where he shows the reduction of a highly coupled set of classes representing a graph structure to a set of integer indices) is the "nearly ideal" state, the nature of which is talked about a little in the section on the bean line

Lakos book cover

Levelization is one of those magic agencies, like Spring, a simply mechanical agency that can improve your code. Sometimes the refactoring required on your code is not obvious, due to the way it was conceptualised during its design - but simply looking for a properly levelized design can create enough pressure to give you the idea how to do it - which usually does require some actual thinking. Levelization is like an altimeter showing you the distance to a good design - you still have to use your legs to walk up the hill!

To summarize, the BeanLine discussion mentions that, following Lakos, "good" designs consist of i) a strict knowledge hierachy, ii) arranged in as flat as possible a shape. Lakos defines a measure of "cumulative component dependency" (CCD), as follows:

The Cumulative Component Dependency, CCD, is the sum over all components Ci in a 
subsystem of the number of components needed in order to test each Ci incrementally.

Good (testable, stable, robust) designs seek to both maximise the number of components C_i while at the same time minimising the CCD.