Within the SOA design patterns catalog, these domains are represented as service inventories – collections of independently standardized, governed and owned services. A service inventory is the real world implementation of what you may have documented in a service catalog or service portfolio. When applying the Domain Inventory pattern, it is assumed that an IT enterprise will have at least two service inventories, each of which is defined and evolved on its own terms. In fact, it is not uncommon for larger organizations to eventually produce dozens of domain inventories.
During a recent podcast interview for the InformIT OnSOA channel, analyst Joe McKendrick asked how this pattern is different from creating "islands of services". In other words, isn't this taking us a step back toward the silo-based, integrated application environments that got us into trouble in the first place? No, it's not. This pattern is about establishing "continents of services", where the scope of each service inventory is defined with an appropriate balance of strategic significance and manageable governance.
"But wait!" shouts the standards police officer, "Won’t this still lead to integration requirements when services across different domains need to communicate?" Yes, officer, this is true. Traditional integration technologies, such as those that carry out Data Model Transformation, Protocol Bridging, and Data Format Transformation, will need to be enlisted when cross-domain inventory services need to be composed. As with any design pattern, there are consequences to its application, and this is the primary trade-off imposed by Domain Inventory. However, because the application of this pattern can begin as early as the initial project planning stages, these transformation and bridging layers are considered an accepted and expected part of the enterprise technology landscape that is shaped around domain inventories. And because they are anticipated, their impacts can be planned for in advance. This mitigates their demands more effectively than when integration requirements emerge unexpectedly after solutions are delivered (as has been the case with typical silo-based environments).