In my OO days most codebases lacked a layer describing what the actual use cases of the system were. You'd maybe have a bunch of 'controllers' in a web app, or a service layer through which everything funnelled, but they were quite light in terms of meaning. In functional programming we talk a lot about pipelines of transformations over data, instead of the chain of policies through which some business information passes. Obviously some people write more or less intention revealing code (and not everybody works in a sort of enterprise environment where this stuff is paramount), but it's rarely taught as the entry point of an architecture. The closest is probably just functional tests, which most people appear to hate, and are rarely first class citizens in your codebase.
I've been wondering lately if there is some space in programming language design to address these issues. One (impractical and not entirely original) thought experiment I've found interesting is this: what if your codebase was entirely append only? What primitives would you want to be working with? You'd probably need more hooks, more late binding, more policy objects, to be able to change processes over time. But out of that you'd get some interesting properties, like a much more structured history of your understanding of each business process, much better than a textual changelog. There was a brief period where DSLs were fashionable but I'm not sure that's the solution, certainly it doesn't seem a popular approach these days.
Anyway, I found the article interesting. In software there are always two models at work: the model we're implementing in code, and a meta-model in the wider world that causes us to change the implemented model. I wonder if there's mileage in being able to represent _both_ to some extent in the artefacts we build.