That's an excellent summary, and I think it explains what many people (myself absolutely included) got a bit wrong when patterns first became popular in software development some years ago. While I managed to avoid the trap of pattern-itis and try to fit everything into some pattern or other, I still worked with the oversimplification that patterns were simply about a language, a way of communicating. DDD emphasised that very strongly, and it has value, but to see it as only that means missing the vast scope of the original work.

I think most people read books on software patterns and heard about the original inspiration, and (without having read it) assumed it was the same "but buildings". In reality, it is as much a work of philosophy and sociology as it is about architecture - it's about lives and how people fit together more than how bricks fit together. It stands in a long tradition, Le Corbusier, for example, deriving systems for living and modular approaches to constructing space such as the Unité d'Habitation.

It would be fantastic if we could get software people to read this kind of thing before they see what it's inspired in the software world - there's so much more to learn from disciplines older than ours (which is effectively all of them). A more comprehensive theory of building software systems (based on the human aspects, the social, etc., rather than the dry economic and project-management aspects comprising most formal books on such things) seems like a significant step in our little world.