Context
Today it is common for IT departments to have software reuse as a goal.
Problem
Without a clear policy for factoring reusable logic, the chances for reuse are lower.
Forces
-
Reuse requires identifiable reusable elements.
-
Appropriate reuse factoring does not happen by accident.
Solution
Have a clear policy for factoring reusable logic across your architectural layers.
Reusable logic can be divided into the following two categories:
-
Logic which is strongly related to a business object (and therefore a domain type). An example would be customer
account setup logic which is related to the domain type CustomerAccount.
-
Infrastructure logic. For example, logic that allowed e-mails to be sent or documents printed.
Both of these types of logic are highly reusable and are respectively factored into the following two service
architecture layers:
-
Atomic business application services. That is, services which do not depend upon other exposed services for
their realization.
-
Infrastructure services.
The layers that these services live in are lower in the architecture than are service consumers and composite business application services. These services are generally used by
composite business application services (which explains the name).
Although the factoring rules in this pattern are for ensuring that we end up with reusable services that are
appropriate for plugging into composite services, service consumers are themselves reusable (specifically across
multiple service-oriented (SO) solutions).
Rationale
Having clearly identified where the reuse points are in our architecture, we can now:
-
Publish these services to a repository for reusable services.
-
Enable the reusable services in this repository to be categorized.
-
Ensure that we factor reusable logic into these services when modeling service interactions (which is when logic
gets factored across your architecture).
|