Bear with me if you already abandoned layered architecture long ago. You may be quite familiar with the thought that layered architectures often fail to apply the Dependency Inversion principle, and often thereby induce tight coupling of un-modular, un-testable layers.

I wish to do two things in this post. First, I propose that the notion "Semantic Field" better captures the one big idea that layered architecture nearly gets right. Second, I will discuss the One Truly Correct Usage of Layered Architecture In the World in order to show why it's the wrong choice for nearly all other usages.

Semantic Field

"Semantic Field" or "Semantic Domain" is a term from linguistics. Words are in the same semantic field if they are related to the same area of reality. (The word domain is pretty much what you'd call it as a DDDer). Orange is in the same semantic domain (let's call it the fruit domain) as Apple. But it's also with Red in the semantic domain of Colour, whereas Apple isn't. That's how natural language rolls.

Kent Beck used the term conceptual symmetry to explain why he didn't like this code snippet:

void process(){
input();
count++;
output()
}

and wants to change count++; into tally();. Somehow the count++ doesn't seem to be on the same level as the method calls. Indeed it isn't. It's the same feeling you have when you see:

void applyToJoin(Customer customer){
    if(eligibilityRules.validate(customer)){
        membershipList.accept(customer);
        htmlBtnUpdate.setEnabled();
    }
}

that a method dealing in business rules and processes should not also know about html buttons. Semantic Field is the notion we want here. The clean code rule is "One Level of Abstraction per Function" and I propose to rename it as "One semantic field per method". In fact, one semantic domain per class, namespace, module, or ... layer.

This is what layers gets right: The idea that inside a given layer you understand a specific semantic domain, and don't use vocabulary from the semantic fields of the layers above or below you.

Where layers goes wrong is, well, the layering. The belief that all top-level dependencies in a system can be expressed in one dimension, top to bottom. They just can't. Squeezing your code into 1 dimension makes you do contortions that are utterly unhelpful. Strict layering adds to this a second failure mode: It makes you write pointless passthrough code, which ought to be deleted.

(Layering does get a second thing right: no cyclic dependencies. Code with mutual dependencies will try to morph into ball of mud architecture. I'm sure this is half the reason why layered architecture become wildly popular. It was a vast improvement on ball-of-mud).

The One Truly Correct Usage of Layered Architecture In The World

The other reason we were entranced by layered architecture for a decade was the ISO OSI 7 layer model for networking. It seemed so obviously, thoroughly, beautifully, correct.

Each layer is clearly (well, it was clear up to about layer 5, after that it got a bit hazy for some of us) and cleanly independent of the other layers. Each layer is a different semantic domain. The bottom layer deals with physical connectors and with what voltage represents a 1 or a 0 and how a byte sequence is encoded as an electrical waveform. The next layer deals with packets, complete with a destination and a source. The next layer deals  in routes: how to get to this destination from the source. The next layer deals in messages: how to turn them into packages and back again. And so on.
And, the layer-cake picture precisely models the dependencies between the layers. At least to layer 5, each layer relies on and adds value to the layer beneath it.

It was beautiful. It made sense. It was what I wanted my software to look like. It was a siren, luring us all to shipwreck our software on the rock of a beautiful but evil vision of how it should always be.

Why a Layered Architecture is Nearly Always Wrong For Any Other Software System

The bit that isn't wrong

The part of the OSI model that is applicable to 99% of all known software is the separation into semantic fields. This is why we used to say that business logic shouldn't be in the UI layer; html buttons live in a different semantic domain to customers and invoices. (Except: it was the wrong way to put it. The presentation layer does reference business logic because in an interactive system usability is achieved by having the UI reflect the business logic; for instance by hiding options that are not valid for the current user).

The bit that fails miserably

The part of the OSI model that is applicable to very very few systems is the layering. In the OSI architecture the strict layering works because the language of each layer can be defined in terms of layers beneath it. Session, Frame, Bit are in separate semantic domains, but the model allows Frame to be defined in terms of Bit, Session in terms of Frame, and so on.

This is almost never the case in layered business software. The vocabulary of a UI cannot be defined in terms of the vocabulary of commerce and business administration, and the vocabulary of a business cannot be defined in terms of data entities. They just are separate domains. The fact that that second one sometimes works a little bit (you can define a customer–incorrectly–as rows in data tables) is what seduces you into thinking it should work. But it doesn't. You cannot define your business in terms of a data layer.

In particular then, a layered architecture with UI on top is always wrong; and business layer on top of data layer is always, but less obviously and more seductively, wrong. Hexagonal architecture (aka ports and adapters) is a much better model for most systems because it doesn't confine dependencies to a single dimension (in addition to the already well-known fact that it gets your dependencies pointing the right way).

DDD: Treating the UI layer as a domain

Having recognised that user interface is a separate semantic domain, should we apply some DDD thinking and treat it as a bounded context with it's own domain? The domain of an MVC web UI includes controllers, actions, routes, etc. But it must reference business logic all the time when deciding what to display, whether to accept user input, and ultimately to do anything with that input. To some, making the UI layer it's own domain context, and giving it adapters to interface with the business domain seems like over-engineering, whilst others advocate almost exactly that.

I recommend that you should at least be aware that if you do not do this de-coupling (and in MVC web apps I personally almost never have) then your UI layer will have two semantic domains inside it. It's a trade-off, but a sufficiently small one that I would usually come down in favour of which side has fewer total lines of code.