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).
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.