Feature Driven Development

Hi All,

I would just like to get some feedback on some techniques I use in my development. I'm not entirely happy with these so I am hoping there are better ideas out there that i can learn from.

With my PD objects that require persistance I typically use the following pattern:
* Create a PD class (for example lets say I have a class called FXInstrument)
* I then create a PD interface for it to interact with some sort of persistance mechanism (IFXInstrumentDao). It contains methods such as findAll(), findBy(Id), save(FXInstrument), delete(FXInstrument), update(FXInstrument).
* In the SI I would then have a realisation for this interface (something like CachedJdbcFXInstrumentDaoImpl). I really dislike ORM technology so i typically cache objects as i retrieve them inside this class myself (Contrary to popular belief it isnt that hard to write and maintain.

So what i have so far is something like:

IFXInstrumentDao ---------- FXInstrument
/ \
|
|
CachedFXJdbcInstrumentDao

In the FXInstrument class I have a static variable that holds the Dao. Something like:
private static IFXInstrumentDao dao = DomainFactory.findImplFor(IFXInstrumentDao.class);

I then expose my PD object to others (rather then letting any other class know about my Dao). I typically don't require Description objects so i collapse those methods into my PPT objects. To be honest I have rarely used a Description object in the systems i have built. What i end up with is something like FXInstrument.findBy(Id) and FXInstrument inst = new FXInstrument(...); inst.save(); etc. These then delegate down to the dao. What i like about this is the detail about persistence is hidden from the client of that object.

Is this a good approach? Or is it ok to expose Dao's to other PD objects and SI/UI clients? What if one has heirachies (e.g. FXInstrument has subclasses like Spot, Future and Forward etc.) that also need persistance to different tables?. Would it be better to modify the static finder on Instrument to support finding by class as well? e.g. Instrument.findBy(Id, Class), or introduce more Dao's for each subclass and introduce a Description-like object to do things based on type?

Another question i have is around compound domain object instantiation and start up order. What if when building the state of my domain object on start up i run into compound construction issue.

For example, lets say that as part of building my FXInstrument object I require some configuration data (loaded from my database) and then some extra data from a 3rd party provider (SI component) in order to fully instantiate my object. At the moment i think creating something like a FXInstrumentConfiguration object to encapsulate the database side and then creating my 'real' FXInstrument class when i get my 3rd party information sounds ok, but it seems weird i would have a seperate dao for configuration outside of my FXInstrument class. An alternative might be to create a builder object and an in memory cache for it, then when the 3rd party data arrives simply look up the partially constructed builder and add the remaining data. I ask this question as during start up when i have PD objects that need other objects configured first before starting up themselves, partially constructed PD objects are a pain, especially in a massively multithreaded system. For example lets say i have listeners that need to be set up on my FXInstrument class. These can't be loaded from the database until the FXINstrument class itself is properly constructed! This introduces different kinds of dependency in that all threads and objects in the PD now need to know about a universal start up coordinator which can introduce barriers!

Any ideas anyone has are most welcome!

:: mark angrish