Cross-Domain Utility Layer

How can redundant utility logic be avoided across domain service inventories?

Problem While domain service inventories may be required for independent business governance, they can impose unnecessary redundancy within utility service layers.
Solution A common utility service layer can be established, spanning two or more domain service inventories.
Application A common set of utility services needs to be defined and standardized in coordination with multiple project teams and inventory owners.	Impacts Increased effort is required to coordinate and govern a cross-inventory utility service layer.
Principles Service Reusability, Service Composability	Architecture Enterprise, Inventory

Table 6.5 – Profile summary for the Cross-Domain Utility Layer pattern.

Problem

The primary reason for enterprises to proceed with multiple domain service inventories is to allow for the governance of individual inventories by separate groups that represent the respective domains. More often than not, these inventories are associated with organizational business domains and the governance issues pertain to the design and evolution of business service layers. The rationale is to tolerate the use of different standards and increased redundancy across business service layers within domains for the benefit of feasible inventory implementation and governance processes.

However, the utility layers within these domains have no ties to business models and often the corresponding utility services encapsulate enterprise resources that are common to all domains. As a result, some utility logic created for one domain will tend to be functionally similar (or even identical) to others. The resulting redundancy and design disparity within multiple utility service layers is therefore wasteful and unnecessary.

Figure 6.23 – By having to duplicate functionality across domain service inventories, more utility logic and services are created than actually required.

Solution

A common utility service layer is created for use by multiple domain service inventories, establishing a centralized collection of utility services that accessible to and reusable by services across domains (Figure 6.x).

Figure 6.24 – A cross-domain utility service layer establishes a set of common services that address broad, cross-cutting concerns. Notice how a smaller quantity of utility service logic is required (compared to Figure 6.x) due to reduced redundancy.

Application

It is recommended that in addition to design standards that require domains to use utility services, standard processes also exist within domains to allow for the identification of cross-domain utility service candidates. This service layer is very much a part of the enterprise architecture, and should therefore be established prior to domain service inventory definition.

Note that a cross-domain utility service layer does not need to replace a domain inventoryÕs utility layer in its entirety. Domain-specific utility services can be defined as required and are then further complemented by cross-domain utility services (Figure 6.x).

Figure 6.25 – An enterprise architecture comprised of three inventories that share a cross-domain utility service layer but also allow for domain-specific utility services to be created.

Impacts

One of the reasons to create domain service inventories is to allow for each domain to evolve independently, which is a more manageable approach for some larger organizations.

Requiring that all inventories use the same common set of utility services reduces this independence somewhat. It furthermore complicates the overall governance processes that need to be in place; instead of domain-specific groups that own and maintain domain services, there now needs to be an enterprise governance group that owns the cross-domain utility service layer and ensures that these services are properly utilized within each domain.

Note also that if service inventory domains are based on geographical boundaries, or if domains consist of vastly disparate technical environments, the governance logistics can make applying this pattern can prove difficult.

Relationships

The Cross-Domain Utility Layer pattern changes the complexion of a service-oriented enterprise by impacting multiple domain inventory architectures, and therefore has naturally close relationships with the Domain Inventory and Utility Abstraction patterns.

When applying this pattern, the basic service design pattern language and its associated patterns (as shown on the bottom of Figure 6.x), can now be realized with agnostic utility logic beyond the boundary of a single inventory.

Figure 6.26 – The Cross-Domain Utility Layer pattern increases the reach of shared utility services in support of increased recomposition of utility capabilities.

Case Study Example

Case study content is not available on this Web site.