Pattern 04: Base Architecture on Business Relevant Elements
Improve the robustness of your solution by basing it only on elements that are germane to addressing the business problem.
Relationships
Main Description

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:

  1. 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. 
  2. For each business sub-process, identify a composite business application service to provide the services that it requires.
  3. 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.
More Information