17 November 2006 - 15:32Applying business logic transparently

We are all familiar with the concept of applying various concerns transparently to an application. These concerns are, more often than not, infrastructure concerns such as: concurrency, data-caching, security, running a component in a particular transactional context, etc… A component should not know whether the data it works with comes straight from the DB or from a cache, it should also not know how it is secured within the application. The component should be agnostic of the operational environment.
I think we can apply the same mind-set to business logic. An object describing a FX trade should not care about how it is taxed or how it interacts with various legal entities, these business-logic concerns (such as taxation) should be applied transparently to this object in the appropriate places. To a large extent I am stating the obvious: behavior that is external to a component should be developed outside this component. I see, however, a relationship between applying infrastructure concerns transparently and applying business logic concerns transparently and I see also the failures to do so which end up in components that are bloated and very tightly coupled. I see this relationship, but I find myself unable to express it, I can say only that a good separation of concerns can be achieved if we try to think of various business logic components as components that have to be applied transparently onto a running application.
One last point: a (key) difference between infrastructure concerns and business logic concerns is that the former are way better delimitated: security is so different from data-caching that it is impossible (actually, we should not use this word, everything, even the most horrific architecture, is very much possible, check this out if you don’t think so) to build a component that handles these 2 concerns at the same time. Business logic concerns on the other hand are a lot more fuzzy and harder to delimitate.