Core domain model

The module plugins/org.polymap.core.qi4j provides the abstract domain model framework for POLYMAP3. This domain model ist used to do the internal model of POLYMAP3, including entities for IMap (project), ILayer, catalog, services, etc. The model and implementation is based on the   Qi4J modelling framework.

Update: We have droped the polymap framework org.polymap.core.model in favour of the   Qi4J modelling framework. This framework meets the reqirements of POLYMAP3 quite good. The API definition of the domain model still is in the package opg.polymap.core.model, while the implementation is now provided by org.polymap.core.qi4j.

Implementation requirements

The implementation of the model framework has to meet the following requirements:

Objects and Relationships

  • an object consists of attributes (fields) and relationships to other objects
  • fields can have all primitive values
  • fields can have complex values (??)


  • load/store from/to persistent store
  • partially load/store the model (avoid serializing the entire model on a single field change)
  • save model evolution
  • XML to allow direct editing without UI (?)
  • locking support (optimistic and/or pessimistic)

Undo & Change Propagation

When a user has changed the model all other session has to be updated. Just reloading the domain model from the persistent storage does seem to be an option. It would force all users to reload their entire workbench on every change any user has commited, even if the actual working set would not be affected. See org.polymap.core.operation for more detail.

Nested domains

The concrete domain model of a user session can consist of several nested domains: Global, Group, Private. A user can "see" global maps and layers. Besides he can create his own maps. These maps are not visible to others. The private model objects can be moved to the global domain and vice versa.

  • let one user session see the model of several domains
  • allow update of the models (keep track of the domain it comes from)
  • allow objects to be moved between the nested domains

Qi4J -

  • can handle authorisation? (and/or separate domains?)
  • persistence: performance? human readable?
  • supports operation concept?
  • native field manipulation undo? advantage?

Why not EMF?

Although uDig is based on  EMF - POLYMAP3 is not. Please read the great aricles on Those articles decribe in detail what Qi4J is and what are the fundamental differences to other approaches like EMF.

I tried very hard to adopt EMF but failed. The reasons are:

  • I need a tool that supports me to model the domain, but let me write and organise the code
  • EMF is exactly the opposite: it polutes my code with (ugly) artefacts but does not support basic things like Sparation of Concerns
  • in fact EMF breaks SoC for itself; with those implementation related code inside the domain code it is very hard to follow an algorithm or, even worse, model and handle different algorithms that a class might be involved with
  • the tools to automatically generate/handle the framework specific code inside the domain code does not cure this; the opposite: they introduce another dependency and more muddle.
Trac Appliance - Powered by TurnKey Linux