When developing a Service Oriented Business Application (SOBA), you want to seperate your user interface from your services.  Services present chunks of data in a manner that is tied to the underlying business rules, but in order to keep your objects fairly independent, you will want a thin layer that the U/I classes use to call the services.

The aggregation layer is responsible for the following things:

– Knowing that the data is coming from services, instead of local configuration or direct database calls.  The U/I layer should know NOTHING about which service is used.

– Knowing how to compose the objects from various services.  More on this second point below.

The driving reason to create a layer of code here is that you want it to be easy to replace a service.  This allows not only the easy change in business rules, but also changes in underlying systems, to occur independently.  However, to make that work, you may need to partition your services so that one service does not refer to a partner service unless it absolutely must. 

For example, let’s say that I have a service that returns information about an invoice.  I can ask that service for all of the data items on that invoice.  One of the data items is the customer id that I sent that invoice to.  However, the invoice service should NOT return a customer object.  Instead, the data aggregation layer, if it needs to get data about the customer, would turn around and call the customer service, using the customer id returned in the invoice object.

It is perfectly appropriate to optimize this a little if the invoice has some fields that are rightly “customer” fields, like the name of the customer company, the address the invoice was sent to, etc.  In a real sense, an invoice is a legal document, and these are data fields that would appear on the document, and therefore should be kept as part of the invoice anyway.  However, if the front end needs data that would not reasonably be kept with the invoice (like the current list of shipping addresses), then the aggregation layer needs to get that information from a different service.


By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

Leave a Reply

Your email address will not be published. Required fields are marked *

seven + 2 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.