This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Architecture, Business Rules, and Aspects, oh my !
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I've been reading a lot from the agile management blog lately, and I came upon this entry about implementing business rules with aspects. If you haven't yet read this previous entry about the division of the system architecture not only along system lines, but also along "risk of change" lines, then I suggest you read it first.
First of all, I would like both developers and managers to read the previous entry because of its profound meaning. We CAN and should separate different parts of the system having differing levels of risk. Once again, "3-tier architectures" don't address these issues.
So, if we are dividing the architecture along risk lines as well, then obviously the UI would be the riskiest - having the highest probability to change - over the life of the project. However, business rules are often considered quite stable. Why ? Because their time-line of change is often stretched out over many project life-times - rather obvious really, business rules deal with the business, not the project. During development of the project we are often given the requirements in such a way that it is difficult to know what is domain knowledge and what is a business rule. It takes effort to separate out what are the business rules - what has changed in the past, and what will change in the future.
For example, in an academic project I performed some time ago, I was given a set of requirements including:
1. A student can register to a given course once in a semester.
2. A student can register to a project in a semester.
Which is the business rule, which is the domain ? In this case (1) is the domain, and (2) is the rule - "a project" meaning "only one project" as I later found out. This rule changed sometime after my second alpha to "A student can register to only one project alone in a semester, but several projects in the same semester as long as they have a partner for each of those projects."
As it is apparent, I, as a developer, have to take into account these risk/change factors and change my architecture accordingly. Ever since that project I have always created a business rules layer separate from the infamous "BL" ( Business Logic ).
Now, getting to the issue of implemeting using aspects. I am a big proponent of AOP, however I often find alternative implementations to be more desirable. Most of the examples given for the use of AOP including logging, transactions, security and others that can be made part of a framework, as .Net has done in many cases. Many have pushed Java's superiority because of AspectJ, and although .Net doesn't have an Aspect.Net yet ( although various developments are under way ), I have yet to miss it. Clemens Vasters has done some truly incredible stuff in the use of attributes in .Net for implementing AOP stuff. I've always thought that attributes should be used that way.
I find that there is one basic flaw in the conclusion to using aspects for connecting business rules to systems. The entire white paper is here. ( Yes, its a pdf unfortunately - only good for print really, Jakob Nielsen thinks so too. ) The basic premise is that I'm building an entire system in an OO manner, which I've stopped doing some time ago for these reasons. Clemens has great insights on this as well, see them here.
When using an SOA, your UI, or any other system needing services for that matter, will be sending messages to the guts of your system - the "BL" for you hardcore 3-tier-guys. Let's call the thing receiving messages in this case the Gateway. All the gateway does is receive messages ( like "Register student number 12 to course number 15 in semester 21" ) and pass them on to the appropriate handler. The word "handler" hear is used like in the term "event handler" for a reason:
The receipt of a message is an event.
In the white-paper the authors refer to these events as a problem that has to be dealt with. Why ? Because when working in an object oriented fashion, you would have to intercept the call to:
new Student(12).RegisterToProject(93);
in order to handle the event, ie check/activate a business rule. Aspects are great for this sort of thing. However, when working in a service-oriented fashion, you would send a message of type "RegisterStudentToProject" with the parameters StudentID and ProjectID as above. No need to intercept any call since it has to first go through the gateway. The gateway would then pass the message to the business rules engine which would then find and activate the appropriate rules before and after the actual call to register the student. The rules engine does something like this:
If ( ActivateBusinessRulesForMessageAndReturnTrueIfCanMakeCall(myMessage) )
{
MakeCallForMessage(myMessage);
ActivateBusinessRulesAfterMessage(myMessage);
}
The business rules themeselves are implemented in a separate layer than the engine. The mapping between rules and messages is also done in a layer separate from both the engine and the rules. Once we have a layer for each of these, we have architecturally separated the parts that change more often in the system from the rest of it.
One can also move to a more dynamic model. One in which you define a language for defining rules, and the mapping to messages as well. Thus, changes could be made by changing a configuration file instead of recompiling any part of the system.
Note that when you have lots of rules and the order for activating them matters, you should move to a commercial rule engine instead of implementing your own. You'll see that performance becomes an issue as the number of rules increases.
I hope that I've managed to introduce yet another strength of the SOA over the pure OO paradigm.
Tell me what you think !
Where does the SOA fall short ?
Where does the OOA beat the SOA ?
Am I full of it ?
Previous Topic
