In addition to making the generated code smaller, bene?¬?ting the developer, the
domain framework also helps the metamodeler. It insulates the generator from
changes in the components, and at the same time allows us to make concessions to
ease of generation, without changing the components themselves. In many cases, the
components have arisen from spotting repeated patterns in the code, rather than being
systematically architected for the problem domain. The domain framework thus also
offers us a chance to provide a more domain-oriented, less implementation-oriented,
interface to existing proven functionality.
Before this starts sounding like too ambitious a project, let??™s reassure ourselves.
The domain framework does not need to raise code to a rare?¬?ed level of abstraction,
easily digestible by any third grader.We have two other layers above it, the generator
and the modeling language, which bear the bulk of that burden: the domain framework
will mostly be invisible to developers. Second, building a domain framework on top
of existing components is not really a new kind of task, simply an extension of
the already familiar task of condensing repeated code into reusable functions and
components. Finally, as layers go, the domain framework is generally thin. Initially it
can be completely empty, and you add to it when necessary, prompted by needs arising
from building the generator.
Pages:
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585