Feature Driven Development

Regarding your first bullet point - keeping PD and SI separate.

This is an article Paul and I co-authored a loooooong time ago, but never completed or published. It's in good enough shape to answer your question though.

Any application, especially an OO one, should be separated or partitioned into these four layers. User Interface (UI), Problem Domain (PD), Data Management (DM - how objects in the PD are stored and retrieved from a database) and System Interface (SI - how external systems are integrated).

UI | PD | DM | SI

In an OO project, the object model is everything and modelling the problem domain is the foundation of the OO approach itself. The PD is the information asset and thus is the highest risk. Without the correct PD we have nothing. A great UI, a DM solution and all the SI are worthless without the PD. The PD is the embodiment of the business solution in code and the separation of concerns allows for the PD to be modelled and implemented independently of the UI, DM and SI. This is a critical success factor for sustainable and flexible OO systems.

The idea of layers and separation of concerns is not new and the classical example of this is protocol stacks from the networking world such as the OSI stack or IBM's SNA. Here there are a number of layers and at most each layer only knows about those adjacent to it. One layer communicates to another via a well-defined interface. That is, a layer provides a well-defined interface for a layer above it (for example) to make use of.

Each of the four application layers - UI, PD, DM and SI - can vary independently. For example, the UI can vary independently of the PD. That is, we could change the UI and not affect the PD, or we could replace the UI with a different one or even have multiple UIs.

The separation of UI and PD is the most well understood and there are several approaches for this such as MVC (model view controller) and model presenter. The implementation is such that there is a one-way dependency from the UI to the PD. That is, the UI has knowledge of the PD but the PD has no knowledge of the UI. This is how the UI can change without affecting the PD. Thus, we end up with a shape like this.

UI-->| PD | DM | SI

The DM layer we tend not to talk about much anymore as we buy a persistence solution here rather than build our own. Thus, we're really only focusing this article on UI, PD and SI.

UI-->| PD | SI

Now, with the SI we want the same kind of independence from the PD as with the UI. Typically, what happens is is that we think of the SI from a technology standpoint. That is, the nature of the system interface being message based, or RPC based and so on. And thus we think of it in terms of send a message and receive or message, or marshalling and unmarshalling data for a remote call. By thinking of it this way we create a dependency from PD to SI.

UI-->| PD --> | SI

But if we do this then SI can't vary independently of PD. PD has knowledge of the SI and even if only a technology change was made - for example, the way we talk to an external system moves from something like RPC to something like JMS then the PD is affected.

What we want is a one way dependency but in the other direction. A much better way to approach this is to not think of the SI in terms of the underlying technology of the other system interface but by moving up a level and thinking in terms of the PD - of the business.

UI-->| PD |<-- SI (this is what we want)

Take for example an external system interface to a credit card system such as CARDPAC. Instead of thinking in terms of marshalling and unmarshalling for a remote call, we think in terms of what business function (features) are required. That is, we need to determine a credit card balance and to check if the card owner is blacklisted.

We can use this "business interface" to achieve the dependancies we want. We define this interface in the PD layer, and in that interface define the methods to support the business features required.

A class in the SI layer then implements the PD interface. Note that this class is a Java class and the SI layer is a Java layer. It is inside this implementation class in the SI layer that we deal with the actual technology required to access the CARDPAC system. This might be via JMS or might be via JNI to native code or whatever is required.

Now other PD classes can delegate calls to the SI layer through this business interface. Typically we gain access to the implementor via some kind of factory class that knows how to dynamically determine the implementing class at runtime from a configuration setting. See the Java implementation example at the end of this article for details on how this is achieved.

*** need a diagram or something here ***

Many applications these days are to webify existing systems. Thus, there is very little in the PD. However, this is also a terrific example of the value of separating the layers.

Consider a UI that is essentially hardwired direct to an SI (a very common implementation these days). Any change to the backend system affects the web front-end (the UI). Even a thin PD layer, with little more than thin classes such as CreditCard in the example above, gives us wonderful separation of the UI from the SI so that each can vary independently.

Even though many see web apps as replicas of old mainframe style non-OO transactional applications, in fact, a proper OO implementation separating the layers has enormous value and delivers on the OO promise of more flexible and sustainable applications.

But wait, there's more! This separation of concerns also enables some concurrency of effort on DM and SI design and implementation as well as UI - after some PD work has been completed.

And, it washes whiter too.

Java Implementation Example

Write the Interface

The key to getting a clean separation is an interface in the PD package that describes the required functionality in business terms. Continuing with the credit card example, we'll define an ICreditCardSystem interface. We populate this with methods that represent each of the business operations that we expect to be supported by our system integration layer. Again we've chosen an example mentioned earlier: a way to retrieve the balance of a credit card.

Write an Implementor

So we have the interface, but someone still has to provide functionality for the business operations we've defined there. We do this with a Java class in an SI package. Note that the PD classes have no direct knowledge of this class, and will only ever see it as something that implements our business interface, ICreditCardSystem.

From the PD classes point of view we don't really care exactly how this class fulfills its responsibilities. It may use some remote call mechanism like RMI, CORBA or XML-RPC, or it might utilise some third-party library that uses a proprietary protocol to communicate with their product. The whole point is that we don't really care and don't need to know.

Build a Factory

So if we don't know about the implementing class directly, how do we get hold of one at runtime? We usually do this via some kind of factory. Most often we use a runtime setting, typically from a properties file, to determine the fully qualified Java class name that we will use as an implementor of our business interface. In this example we have a properties file with an entry like:

com.nebulon.example.pd.ICreditCardSystem=com.nebulon.example.si.CreditCardSystemImpl

So when asked for an object that implements the ICreditCardSystem interface, it looks up the properties file and retrieves a fully qualified Java class name. Using reflection we dynamically instantiate an instance of the class, and check the assertion that this newly created object does in fact implement the interface we are interested in.

A simple factory would have some sort of get<InterfaceName>() method for each known external interface, for example a getCreditCardSystem() method that returned an ICreditCardSystem instance. Here is a simple Factory for this example, implemented as a Singleton.

The getCreditCardSystem method would look something like this:

     1    public ICreditCardSystem getCreditCardSystem()
     2    {
     3        String      name = ICreditCardSystem.class.getName();
     4        Object      impl = null;
     5
     6        try
     7        {
     8            String  fqn = res.getString( name );
     9            Class   cls = Class.forName( fqn );
    10
    11            impl = cls.newInstance();
    12        }
    13        catch ( Exception e )
    14        {
    15            throw new Error( "external system not loaded: " + name
    16                             + ", error: " + e.getMessage() );
    17        }
    18
    19        //  Ensure 'impl' actually implements the interface.
    20        if ( !ICreditCardSystem.class.isAssignableFrom( impl.getClass() ) )
    21        {
    22            throw new Error( "doesn't implement ICreditCardSystem: "
    23                             + impl.getClass().getName() );
    24        }
    25
    26        return ( ICreditCardSystem )impl;
    27    }

A more generic factory might have a single get method that takes the interface class as an argument, but only returned a generic Object value. It could ensure the object was typesafe, but the caller would still have to do a type-cast themselves.

The more generic method would look like this:

     1    public Object getImplementor( Class what )
     2    {
     3        String      name = what.getName();
     4        Object      impl = null;
     5
     6        try
     7        {
     8            String  fqn = res.getString( name );
     9            Class    cls = Class.forName( fqn );
    10
    11            impl = cls.newInstance();
    12        }
    13        catch ( Exception e )
    14        {
    15            throw new Error( "external system not loaded: " + name
    16                             + ", error: " + e.getMessage() );
    17        }
    18
    19        //  Ensure 'impl' actually implements the interface.
    20        if ( !what.isAssignableFrom( impl.getClass() ) )
    21        {
    22            throw new Error( "doesn't implement " + name + ": "
    23                            + impl.getClass().getName() );
    24        }
    25
    26        return impl;
    27    }

But now a caller would have to typecast the result, like this:

 
          sys = ( ICreditCardSystem )factory.getImplementor( ICreditCardSystem.class );
 		  

Despite this ugly typecast of the result, there is some advantage to using this approach. It effectively decouples the factory class from any other PD packages where the various business interfaces might be defined. In this simple example we've placed all the PD classes into a single package, but in any non-trivial application we'd most likely have many different sub-packages defined under PD. If we chose the simpler Factory approach, we'd end up with two-way dependencies between our Factory and these various other PD packages.

In addition, we can easily add new business interfaces to the PD-SI boundary without the need to ever go and update the Factory class. By simply placing a new line in the properties file the Factory will behave correctly.

Delegate to an Implementor

Now we've got all the pieces to the puzzle, we can use them to delegate from any of our PD classes. In this case we might have a simple CreditCard class, that suprisingly wants to be able to retrieve its balance.

The getBalance method would look something like this:

    public BigDecimal getBalance()
    {
        // Use the factory to create an instance of the si class that implements
        // the ICreditCardSystem interface.

        ICreditCardSystem sys = Factory.getInstance().getCreditCardSystem();

        // Call the getBalance method on the implementing class and return the
        // result to the caller.

        return sys.getBalance( cardNumber );
    }

Here is the getBalance method shown as a sequence diagram:

Summary

We've seen how to break the PD-SI dependency into a one-way dependency from SI onto PD. With this implementation we can also swap the implementation of the SI logic without affecting the PD classes by simply changing our properties file.

This is a huge bonus during development. Once the interface is defined, we can easily write a "stub" SI implementation so that unit testing of PD classes can be carried out without any real SI work having been done. Similarly then writing the SI implementation we can write some dummy PD "driver" classes to exercise the SI classes so these can also be tested independently.

It's not uncommon that the PD and SI development happens at a different pace. You might want to put more effort into PD at first to reduce risk. Often you find that although SI might not end up being a huge number of lines of code, the elapsed time to develop this code is greater. Allowing development of each to proceed more independently is a huge benefit, and being able to test each in isolation to some degree before plugging them together generally leads to fewer surprises when you do.

Jeff De Luca and Paul Szego

regarding your third point - business processes and workflow.

You're right - FDD doesn't say anything about it (explicitly). FDD doesn't say anything explicit about a lot of things. It's not a defined, prescriptive, stereotypical (i.e. unchanging and unvarying) process. It's much more like an agile process framework. It is much more of a system though than a collection of practices (e.g. XP) and it has focused more on the system aspects than many of the discrete practices or techniques. In some cases it says to do a certain practice or technique explicitly such as inspections - but it doesn't tell you how to run one. In other cases it is much more implied - like coding standards.

In working on a better set of FDD processes the expression of certain techniques and practices is one of the things I am contemplating. That is - there are many that I always do, but which ones should be brought into FDD explicitly. Clearly coding standards is one that should, but then there is a whole mini-system to do with inspections and coding standards and how they should be symbiotic. How much of this to bring in explicitly is a complex question and the essence of what makes a good well-bounded process framework.

Jim Highsmith has a slide that quotes Dee Hock (of VISA) that expresses this well. From memory it goes something like...

"Simple, clear, precise rules lead to complex, intelligent behaviour"

"Complex rules lead to simple, stupid behaviour"

Jeff

Answered in this long thread.