Domain Inventory is a design pattern, applied within the service-orientation design paradigm, whose application enables creating pools of services, which correspond to different segments of the enterprise, instead of creating a single enterprise-wide pool of services. This design pattern is usually applied when it is not possible to create a single inventory of services[1] for whole of the enterprise by following the same design standards across the different segments of the enterprise. The Domain Inventory Design pattern by Thomas Erl asks, "How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?" and is discussed as part of this podcast.

Rationale

As per the guidelines of the Enterprise Inventory design pattern, it is beneficial to create a single inventory that spans the whole of the enterprise as it results in services that are more standardized, interoperable and easily composable. However, there may be situations when a single enterprise-wide inventory cannot be created. This could be because of a number of reasons including:

  • management issues e.g. who will own the services and who will be responsible for their maintenance?
  • the organization is spread across different geographic locations.
  • different segments of the organization are supported by different IT departments and the technologies used are not the same.
  • some segments of the organization might not be ready for transition towards service-orientation.
  • a pilot project needs to be undertaken just to ascertain the effectiveness of SOA.
  • as per the guidelines of the Standardized Service Contract, it may be very difficult to create standardized data models across the enterprise.
  • cultural issues, e.g. IT managers not willing to give up control they have over the way different projects are developed.

Considering the above-mentioned factors, it is rather more practical to build smaller groups of services whereby the scope of a group relates to a well-defined domain boundary within the enterprise.[2] This is exactly what is advocated by the Domain Inventory[3] design pattern. By limiting the scope of a service inventory, it becomes easier to develop and manage a group of related services.[4]

Usage

Diagram A
Diagram A
An enterprise consisting of two domain inventories. Services in each inventory are standardized independently according to the established boundary of the domain.

In order to apply this design pattern, a well-defined boundary needs to be established inside the enterprise that would usually correspond to a particular business area of the enterprise.[5] For example, sales department, customer services department, etc. It is important that any domains created relate to the business domains as it helps to keep the service inventory in sync with the business models as they evolve over time. Having established a well-defined boundary, the next step is to create a set of design standards that would regulate the extent to which the service-orientation design principles would be applied and any other related conventions, rules and restrictions e.g. how to create the data models, how to name the service functions, etc. By having these design standards in place, standardized set of services can be developed that are specifically attuned to work within the limitations of the respective organizational segment. As the services are standardized, they can be easily composed without the requirement of any bridging mechanisms.

Considerations

If the established boundary of a domain does not correspond to an actual business domain then it might prove difficult to maintain such an inventory of services because of the managerial cross-over. Each domain inventory now corresponds to a specific set of standards that may be different from rest of the domain inventories. As a result, when it comes to composing a solution out of services that belong to different domain inventories, some sort of transformation mechanisms may be required in order for the messages to be sent between different service inventories. For example, services within domain inventory A may be using XML schemas that are less granular as compared to the schemas used by the services belonging to domain inventory B. Design patterns like the Data Model Transformation,[6] the Data Format Transformation[7] and the Protocol Bridging[8] design patterns can be applied in order to address the different transformation requirements.[9]

Another important factor is that as different domain inventories are being built by different project teams, there is a higher chance of developing services with duplicate functionality as each team is unaware of the requirements of the other business processes that are being automated.

References

  1. ↑ "Service Inventory". Archived from the original on 2010-03-13. Retrieved 2010-03-07.
  2. ↑ Mauro et al. Standardized Device Services – A Design Pattern for Service Oriented Integration of Medical Devices [Online]. Date accessed: 7 April 2010
  3. ↑ Domain Inventory design pattern
  4. ↑ Mauro. et al. Service Oriented Device Integration - An Analysis of SOA Design Patterns. Archived 2011-02-03 at the Wayback Machine [Online], pp.1-10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 7 April 2010.
  5. ↑ Thomas Erl,Herbjörn Wilhelmsen Domain Inventory pattern[Online]. Date accessed:7 April 2010.
  6. ↑ "Data Model Transformation design pattern". Archived from the original on 2010-02-13. Retrieved 2010-03-07.
  7. ↑ Data Format Transformation design pattern
  8. ↑ Protocol Bridging design pattern
  9. ↑ Thomas Rischbeck.ESB Pattern: What Is the ESB?[Online].Date accessed: 22 April 2010.

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.