Study the Domain Model
In this example, we consider a domain model for a servicing and sales domain. The preliminary domain model is
shown below.
Figure 1. Preliminary domain model
For simplicity, attributes are not shown here. This is a simple model -- little is shown, other than
association relations. Upon further study, the model is refined to show the following relationships and
multiplicities:
Figure 2. Domain model refined with relationships and multiplicities
The major changes here reflect the following decisions and understandings:
The association between AccountApplication and Customer should be a shared aggregation, as an
instance of account application has one or more instances of customer. Given that a customer can be related to
many account applications, it would not be appropriate for this to be a composite aggregation. In that case,
deleting the account application would delete the customer -- and that is not the desired result!
The same holds true for the association between CustomerAccount and Customer.
The associated instances of AccountApplication and CustomerAccount are required to be associated with the same
instances of Customer.
The association between Customer and Address should be a shared aggregation, as an instance of a
customer would have one to many instances of an address. However, more than one instance of customer can be
related to the same address and vice versa.
The association between AccountApplication and Product should be a shared aggregation, as an instance of an
account application would have one or more instances of product. However, more than one instance of account application
can be related to the same product.
Again, the same holds true for the association between CustomerAccount and Product.
Identify Data Elements with Strong Affinities
From examining the above domain model, we see that CustomerAccount is the "root" of a tree of strong relationships that
includes AccountApplication, Customer, Product, and Address. Per the next diagram, we identify that group of five
elements as an affinity group.
Figure 3. Domain model with a defined affinity group
Map Information Services to Each Domain Type
We would identify a candidate service for each of the seven domain types in the above model. These nominally
would be used to provide access to individual instances of each type.
Map Information Services to Affinity Groups
We also would identify a candidate service for the CustomerAccount affinity group. This would provide access to the
network of instances that comprise an instance of the affinity group.
Update Candidate Service Portfolio and Service Hierarchy
The eight new candidate services would be added to the portfolio and they would be positioned within the service
hierarchy.
Certainly, we would need to add some supplemental documentation to further describe the new candidate services.
For example, one or more new diagrams could be created, which would show the mappings between the new SoaML
Capabilities (candidate services) and the domain elements they manage.
|