Entity Abstraction

How can agnostic business logic be separated, reused, and governed independently?

Problem Bundling both process-agnostic and process-specific business logic into the same service eventually results in the creation of redundant agnostic business logic across multiple services.
Solution An agnostic business service layer can be established, dedicated to services that base their functional context on existing business entities.
Application Entity service contexts are derived from business entity models and then establish a logical layer that is modeled during the analysis phase.	Impacts Entity service modeling is new to many organizations and may therefore may be difficult to adopt.
Principles Service Loose Coupling, Service Abstraction, Service Reusability, Service Composability	Architecture Inventory, Composition, Service

Table 5.8 – Profile summary for the Entity Abstraction pattern.

Problem

When attempting to abstract business logic, there is a natural tendency to group together logic associated with a specific task or business process. Any potentially reusable business logic is embedded together with process-specific logic. Therefore, the reusability potential for this logic is lost.

Additionally, the business analysts who have entity-level expertise are often different from those who have process-level expertise. When entity and process logic is grouped together in support of automating a particular task, it is usually owned by the analysts responsible for the business process definition. This can result in missed opportunities to incorporate design considerations specific to business entity rules, characteristics, and relationships.

Figure 5.33 – Solution logic associated with the processing of specific business entities is added to (most likely task-centric) services as required and therefore is dispersed (and perhaps redundantly implemented) throughout the service inventory.

Solution

To carry out its business, each organization deals with different Òbusiness things,Ó like people, documents, and other organizations. These things are referred to as business entities. As organizations change the way they do business, new tasks may be required or existing tasks may need to be altered. But throughout all of this change, these new or revised tasks usually continue to involve the same business entities.

When looking for ways to design multi-purpose services that have a lot of reuse potential, it is therefore considered a safe bet to build services based on business entities. These entity services are naturally multi-purpose because each can be reused to help automate different tasks. This pattern partitions business logic that is evidently multi-purpose into a separate set of services with functional contexts based on business entities.

Figure 5.34 – A layer of entity services each of which encapsulates processing associated with a specific business entity (or a group of related entities).

Application

To apply this pattern, the service modeling process needs to be carried out to identify and group logic appropriate for entity service encapsulation. Subsequently, the service-oriented design process for entity services must be executed to create Standardized Service Contracts based on business entity contexts.

Often a logical data model or an enterprise entity model provide the source for these contexts. Service boundaries can be derived from entity representations, thereby establishing a clean context that can group functionality associated with the processing of a specific entity.

The resulting service layer is comprised of a (usually large) collection of agnostic business services that can be reused across numerous different business processes. Each entity service can be owned and governed by a group that includes business analysts with the appropriate subject matter experts.

Note that the granularity of entity service contexts can sometimes vary. Although deriving a single service context from a single business entity results in a cleanly modeled service layer, this approach is not always possible. Practical considerations sometimes require that a service context be based on multiple entities – or – a single entity may form the basis for multiple service contexts (Figure 5.x).

Figure 5.35 – The parts of a business entity model encapsulated by entity services can vary.

Impacts

Although there is tremendous business benefit to establishing an entity service layer, it is a foreign concept for many organizations. It imposes change on several levels, not limited to just analysis and design processes. Because a significant portion of business logic now is positioned as enterprise resources geared for reuse, a great deal of attention needs to be focused on its subsequent governance and evolution.

The application of this pattern can shift resources, change the complexion of project teams, and introduce new skill set requirements. Therefore, Entity Abstraction should be incorporated as early in the planning stages as possible, so as to give all of those involved with service modeling and service design enough time to understand and accept the nature of this service layer.

Relationships

The Entity Abstraction pattern can be viewed as a business-centric application of the Agnostic Context pattern (bottom left of Figure 5.x), due to its relationship with the Business-Driven Context pattern. It is therefore also closely related to patterns that support the definition of agnostic business services, such as Logic Centralization, Contract Centralization, Service Normalization, and especially Capability Recomposition.

As discussed in Chapter 8, services with a functional context based on business entities tend to require the application of the Service Decomposition pattern at some stage. They also raise further business logic-related design considerations that carry over to contract design, which is where patterns such as Validation Abstraction and Legacy Wrapper may be required.

Figure 5.36 – The Entity Abstraction pattern combines the agnostic context with a business-centric context, which is why it relates to a number of different design patterns.

Case Study Example

Case study is not available on this Web site.