Example: Identifying Candidate Services from Domain Models
This example illustrates the steps performed to identify candidate services from a domain model.
Relationships
Main Description

Study the domain model

In this example, we consider a domain model for a servicing and sales domain.  The preliminary domain model is shown fin Figure 1.

Figure 1. Preliminary sales and service 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 in Figure 2.

Figure 2. Model 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.  In Figure 3, you identify that group of five elements as an affinity group.

Figure 5. Identify an 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, as shown in Figure 4.

Figure 4. Identify a candidate service

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.

More Information