There are some that can walk up to a white-board and (repeatedly and predictably) create a domain object model representing complex business requirements. One directly convertible to code.
They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain.
These higher order patterns represent those business processes, as you call them.
Sadly such a skill is very rarely seen, or even in demand, given that data modeling is the basis for most design today.
OK, so that covers data modeling, and I agree with you that that is a rare and yet critical skill. But if I'm envisioning correctly the talents that you're describing, that still leaves a large amount of concurrent/asynchronous logic undescribed/undesigned. I expect you know what I mean; maybe a jumble of words like "multiple superimposed event-driven parallel state-machines" gives the idea.
You mention a "domain object model". Are you talking about diagrams that capture much of the dynamics/asynchronous behavior that I described (in which case, where can I learn about such a diagramming language?) or is it more restricted to the nouns?
I am talking about a domain model of the problem under consideration. That model is the same thing from analysis/design to code. It is independent of technical concerns and plumbing. Independent of a particular interface or mechanism for persistence. I'm talking about using standard programming language features, rather than yet another (diagrammatic) language that requires translation to executable code.
Those technical concerns are dependent on the non-functional requirements of the particular required solution. This includes aspects of concurrency.
I suspect your interested in a "framework" that supports both problem domain modeling and specific technical circumstances?
They can do this because they know a set of higher order patterns, beyond just a knowledge of "objects" and "classes". Beyond just a design approach of identifying classes as the "nouns" in a problem domain.
These higher order patterns represent those business processes, as you call them.
Sadly such a skill is very rarely seen, or even in demand, given that data modeling is the basis for most design today.