GHR's online KCard repository
KCard : Locating components
|
Components
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:
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. |
Ideas to develop
|
