Domain-driven Design Approach for SAP Integration

The Domain-driven Design approach for SAP integration is an important concept that requires clear directions for successful implementation. In this blog post, I’ll be describing the Domain-driven Design concept and how it can be used in SAP integration platforms like CPI/PI/PO. Design concepts and standards within an integration scenario ensure that the objects produced are:

• Easily maintainable
• Robust
• Easy to develop
• Understandable
• Efficient
• Consistent

What is Domain-driven Design?

Domain-driven design was first introduced by Eric Ewans in his book of the same title. DDD describes a concept where the structure and language of a software code is matched to the business domain. For example, a loan application with classes like LoanApplication and Customer. These classes have methods like AcceptOffer and Withdraw. DDD connects the implementation to an evolving model. The aim of the DDD approach is to reduce the complexity of software systems. It focuses on an agile software development process where the software developer and domain expert speak the same language. In a way, DDD eliminates the language barrier. It puts domain experts and developers on a level playing field. This way, the software makes sense to the business side as well—not just to coders. The two sides become a cohesive, tight-knit team.

For a further introduction to DDD the following key terms are important: Context: The setting in which a word or statement appears that determines its meaning. Domain: A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. Ubiquitous Language: A language structured around the domain model and used by all team members to connect the activities of the team with the software.

The bubbles above show a bounded context where the components are semantically and contextually defined. The core domain, which is shown as agile project management core, is the heart of the enterprise strategy. The sub domains support the core domain, and they may also be outsourced. A ubiquitous language is defined in each bubble that can be understood by the domain expert and the developer. The integration from the core domain with another bounded context will be done by Context Mapping, which is shown below.

The red dash in shows how both bounded contexts are mapped with each other. This creates a dynamic between both teams and integrates bounded contexts. For further knowledge on DDD I recommend the following books:

• Domain Driven Design by Eric J. Evans
• Implementing Domain-Driven Design by Vaughn Vernon

SAP’s One Domain Model

SAP also used Domain-driven Design principles for its “One Domain Model,” where the data model for the integration of Intelligent Suite are based on DDD aggregates. Aggregates are a pattern in DDD; they are a cluster of entities and domain objects which belong together.

Implementing DDD for PI/PO

Let’s delve into how the DDD approach can be applied to the PI/PO interface. With the DDD concept, the use of a software component (like data and message types) will be replaced by creating business models and generating the schemas externally. This design concept reuses business models and allows for faster updates of software components. Furthermore, the DDD design concept benefits from a three-component strategy and bridges the gap between business processes and how they’re mapped in PO. The core domain software component is defined on the basis of a business model which is an generated schema. Several business software components are associated with the domain software component. This association enables business software components to use an underlying domain software component. The example below illustrates how it can be applied in PI.

In the software component the service interfaces are defined. They will use external messages from the domain software component. Updates on the schema will be directly imported on the domain software component; then, all business components that are associated with this domain software component will be automatically informed. The integration logic is implemented on the integration software component. This component is directly associated with the domain and business software component.

Software Component Concept

For a successful DDD implementation, a three-software component strategy must be applied.

Business Software Component

The business software component is associated with the domain software component. It includes the service interfaces which refer to the external definition of the domain software component.

Integration Software Component

The integration software component will contain the mapping program like graphical-, XSLT- or Java mapping. That’s where the source and target message is mapped. The domain software component is also used in the integration software component as reference because WSDL or XSD include the messages for the transformation. The following class diagram shows the association of the three software component including cardinality.

The example below shows the three mentioned software components tailored by the DDD concept. It’s an “ExchangeRates” scenario on PI.

Interface Design

Creating an interface first requires the construction of a business model. Support from an Enterprise Architect is highly encouraged. With this approach, the domain-driven design view focuses on business usage. An XSD-schema will be generated from the business model; this will then be imported as an external definition to the domain software component in the middleware. The proxy implementation on the SAP backend side is also based on this interface design. The following image shows the component structure in a superordinate context.

Conclusion

This was a top-down approach for implementing domain-driven design (DDD) in SAP PI/PO. Strategic patterns like business-models are crucial for creating concrete fundamental interface data models. And this approach for SAP integration is one that you can always utilize for reducing complexity across your software landscape. For more insight, feel free to sign up to our blog where we regularly explore various SAP and integration topics.