The Domain Inventory design pattern (REF-1) proposes a solution whereby the IT enterprise is sub-divided into logical domains. We then limit the scope of our SOA project to one of these domains, which is another way of saying that we simply avoid biting off more than we can chew. Because we have the freedom to determine the scope and size of these domains, we can tune any given SOA adoption initiative to an order of magnitude that we are comfortable with. This makes the delivery of all services for that project manageable and allows us to work out the cultural and organizational issues ahead of time, as they pertain only to that limited scope.

Domain Inventory has been an extremely successful pattern in the SOA world. It has not only changed IT's perception of what constitutes SOA, it has essentially empowered numerous organizations to proceed with adoption without following a "big bang" approach that brings with it massive amounts of analysis, investment, and unprecedented (and perhaps unattainable) levels of inter-departmental cooperation.

The term "inventory" in this pattern name refers to a collection of physical services that are subjected to the same design and technology standards. The objective is for services within a service inventory to be intrinsically interoperable so that they can be assembled into various aggregates (called "service compositions") without each such assembly turning into an expensive integration project. In fact, successful applications of this pattern together with other supporting patterns, makes the notion of integration actually fade. No need to integrate something that is already compatible and interoperable.

Another benefit of Domain Inventory is that it allows IT to phase SOA into an enterprise in a controlled manner. Because you take on the overall adoption on a domain-by-domain basis, you can take things one step at a time and build on previous experiences. Over time you can establish a collection of service inventories, each representing their own domain, and each delivered successfully because the overall scope of delivery was limited to be manageable.

It all sounds exceptionally promising, and it certainly can be. However, as with anything in life, there are usually trade-offs. Just about any design pattern comes with its own set of impacts. These impacts are commonly associated with time, money, and disruption. Therefore, it is important that the overall consequences of proceeding with a design pattern be carefully considered in advance. This consideration is important not just because of immediate impacts, but because of the long-term commitment you may find yourself making to the use of a pattern that has been successfully applied.