Layered architectural choices allow dispatching application responsibilities according to specific criteria. In some cases though it can be confusing to dispatch between the 'application' layer and the 'business' layer, because it isn't always clear to understand if a set of functions is within the application scope or in the business scope (or also in the domain scope). This confusion is increased if you consider that application logic just like business logic can be distributed or not (i.e. located on a server rather than on the client), which also needs deciding on.
This last comment (distributing application logic) sometimes surprises people because they consider that if application logic should be distributed then it becomes business logic. Although this is true in some cases in some others it isn't. The definition of application logic is logic which is specific to a given software application. However, for technical reasons, this logic might need distributing (for performance reasons for example, if it makes intensive use of server side resources to perform functions which are light weight marshalled).
This gives two choices to make for these components: business or applicative logic and client or server side. Note that the problem doesn't usually arise for the other typical layers because their technical responsibilities constrain them to a dedicated location (the client for the GUI, the server for the data access, ...).
Business or applicative
The first of these two (applicative or business logic) is a conceptual choice and requires good understanding of the domain to determine if some capabilities could be shared or not by many applications (thus making it business scope). This is important because business logic hasn't got the same characteristics as application logic, as typically it is designed to be reusable, long life, stable, integratable, independent, higher quality, ... So you don't want to implement business logic as applicative logic or vice versa.
Distributed or not
For deciding on the second choice (distributed or not) some elements can help constraining the choice objectively. The list below choices situations in which distribution should be chosen. Of course in the inverse cases, non distributed should be chosen:
- Collaboration: Components on which simultaneous collaborative work can arise must be distributed
- Centralisation: If the component must use centralised resources (software, databases, files, robots, ...) then it must be distributed
- Security: If the component's implementation embeds trade secrets then it is safer to distribute it (and locate it on a secure server)
These are examples of criteria which can provide guidance in making the right localisation and distribution choices. Many other elements must also be taken into account depending on the context.