Pattern 06: Derive Atomic Services from the Domain Model
Improve the management of business-relevant information by deriving atomic services to manage the information items in your domain models.
Relationships
Main Description

Context

A domain model (also called conceptual data model, or information model) represents things that exist in the business world (specific to an identified domain), associations between these things, and any special rules that constrain instances of these things.

Atomic services and service providers (Participants) do not require any services (at least architecturally significant ones) in their implementation.

It is common for business state (data) to be owned by the implementations of atomic services.

Problem

Not having a standard for identifying, naming and scoping atomic services causes data ownership issues.


Forces

  • It is difficult to understand which atomic service owns any given piece of business data
  • Changes to the domain model are not straightforward to be accommodated in the service architecture

Solution

Derive atomic business application services from domain types (also called "entities") in the domain model.
For each domain type, there needs to be a corresponding service whose implementation:

  • Contains logic acting on instances of the domain type
  • Contains logic that persists instances of the domain type that map to instances of elements in the physical data model.

Rationale

Atomic business application services are where data is owned in your architecture, because it is this business data and the reusable logic that acts upon the data that needs to be reusable.

As your domain model provides a view of the business things that exist and therefore of the data that exists in the enterprise for these things, the domain model is a first choice subject to use to derive your atomic business application services from.

Note that:

  • It is now easy to see which atomic services own any given piece of business data.
  • The impact of changes/additions to your domain model are more straightforward to accommodate in your service architecture.
More Information