“The best way to find yourself is to lose yourself in the service of others.” - Mahatma Gandhi
The code we’ve developed and tested up to this point has dealt with data: organizing, accessing, mutating, and transforming it into formats more comfortable to us as application developers. We’ve mentioned that these are the nouns of our GeekSeek project; now it’s time to put these to some good use and take action.
Business logic governs the behaviors which power our applications. As compared with more generic (and cross-cutting) concerns which may be abstracted - security, transactions, object-relational mapping, resource management - business logic lies at the heart of our projects. It is unique to our needs, and no one else can write it for us.
That said, the cross cutting concerns mentioned above (and many more!) are all commonly-demanded by our business needs. For instance, imagine we have a series of services, each of which needing to be accessed by and authenticated and authorized user, and in the context of a transaction. If we were diligently applying proper modularization and encapsulation, we might implement separate functions for the transactional and security enforcement, then call these from our services:
INSERT IMAGE SHOWING MANY SERVICES CALLING A AT THE HEAD AND FOOT A COMMON TX AND SECURITY FUNCTION (Fig 07-01)
A glaring problem with this approach is that while we’ve nicely extracted out the logic for our security and transactions ...