across all business domains. So, it might collate details about their travel, car, building, life,  and health insurance to provide a single view of our relationship with the customer. Another common example is  f , an integration that propagates events from one domain into  another. A common scenario is synchronizing business data such as a customer’s address  that might be duplicated in applications in different domains. Ideally, we would want to allocate cross-domain integrations like  e  and  f  in their entirety to a  specific domain even though they have contact with other domains.  Figure 7-8 Splitting integrations In some cases, the right approach might even be to split the integration into several parts  each of which have a more clear ownership within a domain. In Figure 7-8, Application Y uses  an integration to formally expose an API for general reuse. Domain 1 then has a listener  integration that receives events from Application X, and it then propagates the event data to  Application Y via its new API.  Tip:  Grouping the applications with the component that has the highest likelihood of  change that would impact this component would help align the lifecycle of each. Forcing ownership decisions for these crosscutting integrations is not such a bad thing. All  components in an architecture need an owner if they are to be maintained effectively over the  long term. 7.2.4 Grouping within a domain Having performed an initial split of the integrations based on business domains, we now need  to look for reasons why integrations might need to be grouped within those domains. In the  following diagram there are some possible reasons that we might group integrations together.  In the remainder of this section, we explore the pros and cons of each.  444  Accelerating Modernization with Agile Integration