I see things quite differently. Functional requirements change frequently. Non-functional requirements change infrequently. To be agile enough to respond to business changes, we can't let the architecture depend upon the domain. I lay out my argument in Keep functional and non-functional requirements separate.

Less pedantically, I distinctly remember a generation of applications that were thin "webifications" of desktop apps. These attempted to build a core application independent of the delivery mechanism, precisely as Bob suggests. All of them ended up hopelessly snarled in state management nightmares. They didn't scale, tended to lock up badly (due to database transactions), and were painful to use because they did too many page reloads.

At the root, I think the architecture of a system must balance the forces acting on it. Some of those forces emerge from the application domain, but many of them also emerge from the technology domain.

One of these delivery media responds best to command-oriented transactions that do not rely on keeping state in memory. The other works best when state is kept in memory for rich interaction. With so many fundamental forces in opposition, how could we expect the architecture to be the same?

Would one ever build web applications out of a bunch of .ocx'es in containers? Would one ever build a desktop application out of hyperlinked resources? Only as an exercise in perversity. This isn't because we have bad frameworks or leaky abstractions (though both exist). It's because the fundamental nature of desktop and web applications are different. Ignoring that entire aspect just because it doesn't come from the business domain is irresponsible.

Ivar Jacobson may be best know for introducing use cases, but his book "Object-Oriented Software Engineering: A Use Case Driven Approach" actually included a complete, end-to-end modeling methodology. Use cases are used to capture the requirements of a system, and that does, in fact, drive the rest of the process. But the next step is to do "robustness analysis", which involves modeling system functionality meeting the use case requirements in terms of boundary, controller and entity objects (I believe "boundary" was initially "interface", but that later become confusing with other uses of the term).

What I think is key here is that the BCE pattern is used as part of analysis. It was not intended to provide an overall "architecture" for the system. Indeed, once one adds in consideration of those annoying implementation details, there is an immediate need to control complexity. This then leads to the internal division of a system into subsystems, which can be done in various ways, with various trade-offs. The whole rest of Jacobson's approach handles these sorts of considerations, allocating functionality down to subsystems and then, if necessary, recursively analyzing and designing those subsystems. After all, Jacobson's background was in the telecom industry in which the architecture of very large "systems of systems" is paramount!

Jacobson's own view on all this has, of course, evolved over the years (he is a big proponent of agile these days). But still, to me at least, an important lesson is that architecture has to do with mediating the stakeholder requirements for a system with the engineering realities of building the system. A good analysis technique like BCE can be a crucial link in doing this. But that is really just the beginning of the architect's work.

In any significant system, the devil is often in those annoying details!

In the late 90's I worked on a modeling and transactional coding (just pre-EJB) framework that started with use case patterns tied to BCE analysis patterns on the front end. But there were then two more levels of architectural models before you had worked out all the implementation decisions! Not to mention the possibility of recursing into analysis of the subsystems of a large system.

In order to be able to flexibly handle changes in architectural and implementation decisions, you need to have an explicit record for what those decision were. To me, "agile" really requires being able to quickly and efficiently move back and forth between all these levels between requirements and code.

On the other hand, in my experience, models can be a great way for "a small number of highly experienced developers" (very much the kind of team I like to have!) to communicate amongst themselves and with stakeholders. But models are just a means for communication and documentation toward the end of developing a successful system. Certainly, if the models you are doing aren't helping you do you do your job better and faster, then don't do them!

But that's the topic of a whole other conversation...

Having participated in projects where the model went right down to an implementation level, whether that's for communication or direct code generation, I find it pretty unworkable at any non-trivial scale. Try getting version control set up for a large, very detailed model for instance where many people have to be involved, we used to partition our heavily to try to deal with that, but it was always far slower and more cumbersome for detail work than the code was. Better to just represent the high-level architecture, principles and idioms in the model (and it doesn't even need to be in a modelling tool for that, in fact something more free-form like a wiki was often more powerful) and let the implementors instantiate / specialise the patterns appropriately. Another reason a wiki was better than a formal model was that these implementors could feed back any specialisations or issues for peer review far more easily.