I think any of the modern processes, applied properly, will get you to where you want to go. The more significant issue is how the process fits into an organization. I'm not familiar with REA, but after investigating various processes it seems that some of them are geared to larger or smaller organizations. For instance XP is not suitable for large organizations that need good documentation. RUP is harder to apply in a small organization, but can be done if you use a smaller subset of it. If you learn HOW to apply a specific process well, then it's easier to make the transition to other processes.
More to your question, the separation of the business domain from the implementation domain is a design skill, not a process attribute. This involves being scrupulous about not allowing your implementation details to crop into your design, and is something that can be difficult to achieve in the beginning. ICONIX provides you the capability to do that. It all depends on your skill at performing analysis. One thing to remember, just because you're modeling in the business domain doesn't mean you're not specifying real classes, object, associations, etc.
The other thing to keep in mind is that most of the analysis/design methods like using Use Cases as a start to identity objects and interactions, and are an aid because we as humans tend to think in functional terms. This allows you to perform functional analysis, which you then start and then to organize it in OO terms. If you concentrate on Business Use Cases and don't allow implementation details to creep into them you'll end up with a more business specific Analysis model.
