> > Using such an architecture, one can add or delete any data models > > (remember: data models also means any kind of user interface!) and > > exchange mechanisms without touching any other or changing the whole > > system every time. This is true component orientation/modularization. > > So exactly how does this help us in implementing a reference > prescription module ?
This was meant as a general remark, side-note of mine on the meaning of Frontend and Backend. I guess I got into talking to much then... However, what I meant with System and Model as the two major parts is applicable to any module, also the prescription module. > BTW, Fowler, who happens to be one of the OO gurus, recently > published research on how Agile Programming worked well for > larger projects _including_ database schema work. > > http://martinfowler.com/articles/evodb.html Thanks. Have to read on this. > Thus I am not entirely convinced that I need to follow your > reasoning on why I should not design and use tables before > having recomputed 42 as the answer to the world. (I am not hitch-hiking anymore but still on the journey, trying to find the right way, presumably like all of us.) What I am saying is not that we shouldn't start developing anything at all right now. If I hadn't started to actually code on our system two years ago, I wouldn't have encountered all these problems which need to be solved. (But I found that it is possible and the more I think about it, the clearer it all gets. A good solution can only be an easy one.) I just say that it will be _much more_ effort to code _a lot_ into a still unclear design since then after some weeks/months not only the basic architecture but also all the modules building on it need to be changed. Anyway, it's fine to follow this approach since not everything can be foreseen. Christian
