Skip to end of metadata
Go to start of metadata

Motivation

We want to prevent service rot, duplication and loose coupled services, in other words good building blocks

Argumentation

If a service does more than one thing, it will likely not do everything well. The success ratio of a service correlates nicely with the characteristics of reusable code, namely code which does one thing, and one thing well

Use the service layers to decompose the service and place the parts into the correct layers: see The Laws of SOA paragraph 2.

Exceptions/special cases

Typical misunderstood attempt on an exception:

In some cases you may have to violate this principle for performance reason.

However, the service is probably designed incorrect if this is the case.

Arguments:

  • If you violate this rule, your service will not be re-usable
  • If you violate this rule, your service will duplicate business logic and will be life-cycle dependent on all the services which share data and behavior
  • Exposed data from such services will be incompatible with data from all other services
  • The quick-win scalability argument is better solved with collaborating instances of data-providing services (shared state backbones, eventing backbones and similar state-sharing techniques)
  • See Service governance quiz for detailed discussion.

Definitions

Status

Doc status H2A A2A ACS CS Last PAB discussion
2007.06.08

PAB discussions

Can a H2A service to too little? We should add a new checklist item which ensures that we provide enough business value..


Design-Time Governance - SOA Design Rules FAQ

  • [Question still to be asked..]
Labels:
policy_h2a policy_h2a Delete
policy_cs policy_cs Delete
policy_acs policy_acs Delete
policy_a2a policy_a2a Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.