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.
|