Hi Albert,

I have moved this topic to the developers forum as again I didn't want to bore the users :-)

This topic is a complicated one as it goes back to the original architectural decisions I made when initiating the project.  I was looking for a way to design a database that could cater for changes to the scope of the business model and adapt to new business concepts without the need to constantly add tables and develop associated DAO code to provide API access to these tables.  I was also looking for a way to move the management of these concepts away from the  developer and into the implementor/user space.  Why .. flexibility, customisation, speed of feature development, minimise number and complexity of database updates just to name a few.

In the early days of OpenVPMS I researched a number of architectures and came across the OpenEHR project for Medical Informatics.  This introduced me to the archetype concept which essentially separates the business model into two components - A reference model (database model) and a Knowledge model(archetypes).  The reference model is managed by IT people.  The knowledge model managed by domain experts.  It took me some time to grasp the idea but it dawned on me how this could faciliate the objectives I was looking for.

At that time the idea was a new concept and had only a couple of small, incomplete implementations.  Also the reference model was very medical informatics specific and I thought overly complicated and not generic enough to deal with the range of business concepts we would need.  The beauty of the concept was it did not rely on a specific reference model so we set about working on a reference model that would suit and implementing a business framework API built around this model and our own archetype definition language.  I ended up using some concepts from the HL7 3.0 project in reagrds the reference model design (entities, acts, participations will look familiar). 

It took some time to get the concept straight and a reasonable implementation but I believe the effort was worth it.  From the developers perspective they are able to concentrate on feature development without spending time on database modelling , dao and api deveopment.  New domain concepts such as the recent schedule views are introduced in minimal time by developing and loading a new archetype that typically takes minutes to develop and test rather than days.  The business framework and the generic UI compoents instantly provides all the standard CRUD behaviour for the new business object including collection and relationship management.  I think the stability of the project has also benefited greatly from the concept.

I would be very interested in your views on this from a developers perspective.  Tim, our developer will give you a view from a seasoned archetype user and one who has the most experience on implementing and using the business framework.  He will definitely give you a warts and all insight :-)

Cheers

Tony