> In other words, directly modelling the aspects of reality we are concerned
> with as first-order concepts in the software and database is a recipe for
> costly and permanent maintenance. I believe we have to instead model the
> reality as a second order concept, with first order concepts in the system
> being stable models of the classes of things found in the reality of the
> domain. Hence in openEHR we model only things like Composition ('recording'),
> Section ('heading'), Party, various kinds of Entry like Observation and so on.
> We don't model any medical or clinical thing directly. Everything modelled as
> a first order concept is domain-invariant - it has the same meaning right
> across teh entire domain of application. Of course we can debate whether we
> have gotten it right or not, but this is the intention.
>
Thanks for explaining your view, Thomas.
Doesn't this model division of the problem domain into two concepts just
mean that you're shifting the bulk of development and maintenance
complexity/costs from first order concept level to the second order
concept level? The reality of the problem domain _will_ change over
time, and must be reflected in software somewhere, somehow.
Of course I agree that divide-and-conquer is one of the best strategies
a human mind can work with; especially when at some point in time one
doesn't have to worry anymore about basic first order concepts because
they have cristallized into stability. But this looks very much like
well-known modern programming languages and the libraries (abstract
classes in OOP) available for them. Or is this a wrong analogy?
Roger
