Context
A software architecture defines the software in terms of a set of parts that together make up distinguishable software
systems.
It is common to have in place a standard for identifying, naming and scoping these parts to ensure a common approach is
followed across the organization.
Problem
Identifying, naming, and scoping the parts in your service architecture on things that are not part of the business
view causes problems.
Relevant examples of things outside of the business view are:
-
Existing software applications
-
Component implementation technologies (for example, EJB)
-
Communications "plumbing" between components
Forces
-
The service architecture is affected unnecessarily if parts are based on things outside of the business view and
these things are disappeared or changed substantially.
-
In general, impacts that cause changes to architectural specifications are more serious than those that only
require changes to implementations (changes to one architectural element will typically affect multiple design
elements and an even greater number of implementation elements).
Solution
Derive parts of your service architecture on the following business relevant things:
Here is a simple set of factoring rules for achieving this:
-
For each business process, define a service consumer to serve as a proxy for the business process (see Pattern 12 for more discussion on this). This service consumer will consume any
services that support that business process. If executable business processes are being built, then the executable
business process will form part of the implementation of the service consumer.
-
For each business sub-process, identify a composite business application service to provide the services that it requires.
-
For each domain type, identify an atomic business application service (this is described further in "Pattern 6: Derive atomic services from domain model").
For a fully service-oriented solution, the business process could be realized by a service Participant that assembles other Participants into a ServicesArchitecture, and which then provides entry to the business process using an
exposed service. See Concept: Service Composition and Choreography for further discussion.
Rationale
Deriving parts for your service architecture from business things provides a solid architecture. This means:
-
Your service architecture will no longer be affected greatly by changes to non-business things (for example,
retiring and replacing existing applications, or choosing a new component implementation technology).
-
The architecture will be able to "flex" with changes to the business rather than changes to non-business things.
-
This reduces the number of unnecessary specification changes. Changes to the non-business things listed above still
require software change, but such change will be to detailed design and implementation rather than to the
architecture. These types of changes have less overall impact.
Tip: Some words of warning in applying this pattern:
-
Depending on how the business entities themselves have been factored, you might end up with parts that are "too
big" if you just apply a simple 1-to-1 derivation. In these cases you need a further subdivision to create
"smaller" parts.
-
A bit of creativity and experimentation might be required to create factoring rules that work for you. The
important point is that these rules have to be based on things in the business view.
|