Thursday, October 16, 2003

Business Rules, Object Modeling and FDD

I promised to publish more about The Business Rules Approach by Ronald Ross after I’d read more of it. I also want to relate it to Streamlined Object Modeling, by Nicola, Mayfield and Abney. The latter, shows how to apply business rules into an object-oriented design in a systematic way. So it seemed likely that the two methods were compatible. I have now read both of these books and I believe that there is a benefit in combining the techniques.

Let me save you some effort. The meet of The Business Rules Approach is in Sections 2 and 3. Ignore Section 1 - I found it, boring and wasteful of my time. How to write requirements as business rules is described in chapters 8 & 9 and these are the key chapters.

As I mentioned in earlier posts, The Business Rules Approach divides the requirements space up into 3 areas: Facts (and the Fact Model); Business Rules; and (User) Tasks (though Ross calls them Processes). Let me talk about these in turn.

Facts

Facts and their close cousins Terms describe the domain of a problem. Ross (the author) introduces a new notation for Fact modeling. He did this to avoid confusion with data modeling. Terms are either entities in a domain or attributes of those entities. Facts are relationships between Terms. In addition there are Derived Terms and Calculated Terms - these are also referred to as Functions.

Translation

What FDD calls a Domain Model - Ross calls a Fact Model
What FDD calls a Domain Object - Ross calls a Term
What FDD calls a Feature - Ross calls a Derived Term or a Calculated Term
What FDD calls as Association (on the Domain Model) - Ross calls a Fact

Advantage of Facts

The Fact Model (Domain Model) has a very low variance and changes little -  it is after all based on facts. Regardless of changing requirements in a domain, the Fact Model will suffer very little need for refactoring.

Business Rules

Business Rules describe (primarily) constraints on Facts. [There is that word constraint again].
Such as “A Customer with a Checking Account must also have a Savings Account”

Translation

Business Rules have no direct translation in FDD. We typically write them as notes to Features or simply embed them in Use Cases and cross-reference from the Feature definition.

Advantage of Business Rules

The Streamlined Object Modeling book dedicates a whole chapter (Chapter 4) to Business Rules. It explains how to map them on to a Pattern-Player model (Domain Model - similar to a Domain Neutral Component model using color Archetypes). The advice in this chapter can be mapped directly onto a Domain Model in FDD.

Nevertheless, Nicola and Mayfield observe that business rules are subject to change more often and have a greater uncertainty attached to them. So finding a method of reliably implementing them in code is a bonus.

Ross goes further. He wants them implemented in separate code. His suggestion is that business rules are encapsulated on their own.

It makes sense to separate out business rules during the requirements because they have real business value and are definitely client-valued functionality. This fits with the spirit of “tracking the flow of value”. They are also subject to greater uncertainty and as Donald Reinertsen pointed out in Managing the Design Factory, systems should be partitioned architecturally to decouple uncertainty. It makes further sense to list business rules because Nicola and Mayfield have shown how to map them directly to code. This allows the requirements to be directly mapped to working code which facilitates end-to-end traceability.

Hence, it would seem to be advantageous to build a list of Features and a list of Business Rules in a Value-Driven software engineering method such as FDD.

Process / (User) Tasks

Ross describes Processes but he really ought to call these Tasks or even User Tasks as they describe flows of interaction mainly with the user.

Translation

These are not Use Cases. They don’t have business rules or facts and terms embedded into them. They are more like what Larry Constantine used to call “Essential Use Cases” and later renamed “Task Cases”. Ross’ processes are more like screen flows. They could be represented in a Visual Vocabulary diagram or a UML Statechart.

Advantage of Tasks

The advantage of capturing tasks separately - as my employer does with VV diagrams and I have shown with Statecharts  - is that they can vary independently of business rules and the much more stable fact model. In fact, almost everyone recognizes that UI designers reserve the right to make changes almost right until the end of a project. Bottom line - tasks change often!

Conclusions

The Business Rules Approach offers us the possibility of a new lightweight method of requirements definition which is better able to cope with change and separates out concerns more efficiently - unlike use cases which couple concerns. Ross refers to techniques such as Use Cases generically as “procedural methods of requirements definition”.

The Fact Model - Business Rules - Tasks separation offers us a cleaner mapping between requirements and code. One Term is one Domain Class or ERD Entity or an attribute of a class or entity. One Fact is one association on the model. One Derived (or Calculated) Term is one Feature in FDD. One Business Rule is one Business Rule in Streamlined Object Modeling. One Task is one VV diagram for several Views and Controllers/Actions which are UI Features in FDD.

My biggest conclusion is that The Business Rules Approach threatens to create a paradigm shift - a discontinuity. What it really highlights is that the encapsulation in object-oriented technologies is misguided and of limited real use. It hints at the fact that we need a new paradigm with rules and tasks encapsulated separately. I believe that this gives the Object Role Modeling (ORM) community with authors such as Terry Halpin and David C. Hay a real opportunity to cross the chasm into widespread adoption. It also hints that technologies from Microsoft that are influenced by ORM (MS has never really been an OO shop) may provide a time-to-market advantage over traditional OO technologies like Java. The point being that a system which architecturally partitions uncertainty will lead to faster development and faster subsequent incremental iterations.

Necessary Reading

For those with an interest in this, I would recommend…
The Business Rules Approach  - Section 2 and Section 3
Streamlined Object Modeling  - Chapters 1 thru 4