Domain-Driven Design for SAP Integration: PI/PO and CPI Guide

The domain-driven design (DDD) approach for SAP integration provides a structured methodology for reducing complexity in integration landscapes by aligning software architecture with business domain concepts. When applied to SAP PI/PO or SAP Integration Suite (CPI), DDD helps integration architects create maintainable, robust, and business-aligned interfaces that can evolve alongside changing enterprise requirements. This approach is particularly valuable as organizations migrate from legacy SAP PI/PO to cloud-native integration platforms. SAP Integration Suite consultancy increasingly relies on DDD principles to design scalable integration architectures.

What is SAP Integration?

SAP integration is the integration that takes place within SAP itself or between SAP and 3rd party systems. SAP Integration is important for business continuity and disaster recovery, but also for your company's growth. It helps you lower costs, increase flexibility, and improve productivity. The goal of any SAP integration project is to connect systems that were previously not connected so they can exchange data in real time across the enterprise.

The Domain-driven Design approach for SAP integration is an important concept that requires clear directions for successful implementation. In this post, I describe the DDD concept and how it can be applied to SAP integration platforms like SAP Integration Suite (CPI), SAP PI, and SAP 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 Evans in his seminal book of the same title. DDD describes a concept where the structure and language of software code is matched to the business domain. For example, a loan application with classes like LoanApplication and Customer, with 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 (shown as agile project management core) is the heart of the enterprise strategy. The sub domains support the core domain and may also be outsourced. A ubiquitous language is defined in each bubble that can be understood by both the domain expert and the developer.

The integration from the core domain with another bounded context is done by Context Mapping, shown below.

The red dash shows how both bounded contexts are mapped with each other, creating a dynamic between both teams and integrating bounded contexts. For further reading on DDD, I recommend:

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

SAP’s One Domain Model

SAP also applied Domain-driven Design principles for its "One Domain Model," where the data model for the integration of Intelligent Suite is based on DDD aggregates. Aggregates are a pattern in DDD — they are a cluster of entities and domain objects which belong together. This SAP One Domain Model is the foundation for how SAP Integration Suite connects cloud applications, and it explains why integration content built using DDD principles is more reusable and maintainable. For organizations managing multiple integration processes in SAP Integration Suite, the DDD approach ensures each process stays within its bounded context.

Implementing DDD for SAP 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 a generated schema. Several business software components are associated with the domain software component, enabling them to use the underlying domain 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 contains the mapping program — graphical, XSLT, or Java mapping. This is where the source and target message is mapped. The domain software component is also used as reference because WSDL or XSD includes the messages for the transformation.

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 DDD view focuses on business usage. An XSD-schema is generated from the business model and 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.

Frequently Asked Questions (FAQ)

What is the difference between DDD and traditional interface design in SAP integration?

Traditional SAP PI/PO interface design typically starts with the technical structure of the systems being connected — defining message types and service interfaces based on what the sending and receiving systems expect. DDD flips this approach: it starts with the business domain model and generates technical artifacts (XSD schemas, service interfaces) from that model. This means the integration layer speaks the language of the business rather than the language of the underlying systems, making it significantly easier for business analysts and developers to collaborate on integration projects and for the architecture to evolve as business requirements change.

Can DDD principles be applied to SAP Integration Suite (CPI)?

Yes. While DDD was originally articulated in the context of SAP PI/PO, the principles translate directly to SAP Integration Suite. In CPI, the "bounded context" concept maps to integration packages and iFlows organized by business domain. The "ubiquitous language" is reflected in naming conventions for iFlows, message mappings, and value mappings. SAP's API Business Hub (now SAP Business Accelerator Hub) can serve as the repository for the domain model, providing standardized business data models (like the SAP One Domain Model) that integration content can reference. The DDD approach in Integration Suite makes multi-process orchestration more maintainable and reduces the risk of integration spaghetti.

How does DDD help with SAP integration maintenance and upgrades?

One of the most significant benefits of DDD in SAP integration is improved maintainability. When integration interfaces are built around a domain software component (a shared schema repository), updates to a business data model only need to be made in one place — the domain component — and all associated business and integration software components are automatically informed of the change. This dramatically reduces the effort required for integration maintenance when SAP releases updates or when business processes change. In contrast, traditional integration architectures where each interface has its own hardcoded message types require individual updates to every affected interface, which is both time-consuming and error-prone.

Conclusion

The domain-driven design approach for SAP integration offers a top-down methodology for creating concrete, fundamental interface data models that bridge the gap between business processes and technical implementation. Strategic patterns like business models are crucial for reducing complexity across your software landscape. As organizations migrate from SAP PI/PO to SAP Integration Suite, DDD principles become even more important for ensuring the new integration landscape is scalable and maintainable. For more SAP integration insights, explore our SAP Integration Suite consultancy services.

References

Eric Evans — Domain Language
MDP Group — Multi-Process Management in SAP Integration Suite
MDP Group — SAP Integration Suite Consultancy