Chapter 7. Business Logic and the Services Layer
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 that power our applications. As compared with more generic (and cross-cutting) concerns that can 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 just mentioned (and many more!) are all commonly demanded by our business needs. For instance, imagine we have a series of services, each of which needs to be accessed by an 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, and then call these from our services.
A glaring problem with this approach is that, although we’ve nicely extracted out the logic for our security and transactions for reuse, we must still manually invoke them, sprinkling these method calls at the head and foot of every function ...