Agnostic/non-agnostic revisited

I got the feedback that the previous article I wrote on what agnostic/non-agnostic is was too complex. So I am revisiting the subject to make sure that I explain a lot simpler than in the post I described last year.

To explain as easily as possible what agnostic/non-agnostic is:

• agnostic services are not aware of the context in which they are being called, nor are they aware of how the service is implemented, which platform, technology etc.
• non-agnostic services can have one or more forms of coupling or context (ie. process functional context).

Result of these two statements is that agnostic services have more reuse potential than non-agnostic services.

An example of the difference can be identified by discussing a "PrintInvoice" service capability.

This is a service capability which can be described as the logic exposed to print an invoice. When trying to classify the service it is pretty obvious that this is a non-agnostic service, as it has capabilities to print invoices and nothing else.

When applying the principles of service design, we should give a service a defined logical (functional) boundary, which defines the context in which the service operates.

When redesigning the implementation of this service, we could split the service into two services:

• Print
• Invoice

These are two agnostic services: print service capabilities are bothered with the capability to print "stuff" and Invoice service capabilities deal with invoice related "stuff".

Having made this separation, I just lost my capability to print invoices. To resolve this problem I can create a third service which combines the two services in one service capability which can deal with the mechanics of printing invoices, which results in the following service-inventory:

As you can see the agnostic services are being composed by the non-agnostic PrintInvoice service. This allows for the invoice and the print service to be used for other purposes, of which I have depicted a few potential examples below:

As we can see, it's the agnostic services which are being reused, not the non-agnostic services.

If this separation of concerns would not have been applied, instead of ie. reusing the print functionality, for the printletter functionality, the printing part would have been redeveloped and tailored for the printing of letters. This would have created some unnecessary/redundant/duplicate logic.

The current PrintService would take any range of different document types that it would support. This would greatly enhance the reusability of the agnostic print service.