There is no problem that cannot be solved by adding a layer of abstraction, except for having too many layers of abstraction.
If you have four domains from four disparate apps, and you are attempting to integrate their functionality or data into one app, then use the four domains, with an extra layer on top to handle interop between them; each domain or SOA layer will talk to your new layer, which will facilitate passing data across the borders of each domain as well as up to the application, so the domains can remain unaware of each other as they are in their original apps, and the application layer has one point of contact so it doesn't care how many separate domains lie underneath. Exactly how you architect this is dependent on the nature of the domains and SOAs you are integrating.
If you think of your app in an n-tier fashion, e.g. UI/Application/Domain/DAL/Data, and don't want to think of this new layer of abstraction being its own tier, then consider it as part of the Application layer. However, it is usually best explained as a new tier, "Interop", between Application and Domain layers.
Do be aware of the exception to the rule in the first sentence. Avoid architecting "lasagna code", having so many layers of abstraction between tiers that even simple changes like adding a field require you to spend your day drilling down through all the layers of abstraction. Data, mapping, domain field, service layer (client and server), DTO, application layer, Controller, UI... You could easily end up touching a dozen objects just to add a checkbox to a form if you over-separate. Also avoid the "God Object" when implementing your interop layer; it can be tempting to create one object that can give any object to any other object, but consider Factories and Converters with smaller scopes that are managed by supervisor objects (again, no problem you can't solve with another layer of abstraction...).
