Deploy Isis domain model on your own Framework

The programming model defined by Isis deliberately minimizes the dependencies on the rest of the framework. In fact, the only hard dependency that the domain model classes have on Isis is through the org.apache.isis.applib classes, mostly to pick up annotations such as @Disabled. The idea is to make it easy to be able to write take a domain object prototyped and/or tested using Isis, but to deploy on some other framework's runtime.

If you are interested in taking this approach, note that there is one important interface that must be implemented by your own framework, namely DomainObjectContainer. This interface represents the one-and-only "touchpoint" between the domain objects and the runtime. If you inspect the methods then you'll see it covers such concerns as persistence, and of raising warnings or errors.

Isis' own runtime injects an (implementation of this) interface into each and every domain object. You will likely need to do something similar within your own framework, (or come up with an equivalent mechanism, eg Service Locator pattern).

Note also that although Isis does define a convenience superclass AbstractDomainObject, isn't necessary for domain objects to inherit from it. In fact, the main purpose of this superclass is to provide delegate methods to the injected DomainObjectContainer.

Custom UI

One of the main reasons for going down the custom framework route is to have full control over the user interface, but it does beg the question: why bother with Isis at all?

The answer is that using Isis to write your domain objects will:

  • allow you to build a better/richer/deeper domain model more quickly.

    The key to better domain models is stakeholder feedback. You can use Isis to spike out prototypes, and then feedback the results of the insights gained from those prototypes into more formal development in your actual runtime framework.

  • enforce proper architectural layering.

    Isis only lets business logic to be written in domain objects. Using Isis for your domain model helps prevent business logic creeping into adjacent layers.

    That said, it is also possible to deploy Isis as a REST webservice, so you could choose to implement a custom UI (eg in HTML5) that calls back to an Isis backend.

Custom persistence

Another reason for choosing the custom framework is full control over persistence. That is, you can use whichever persistence technology you prefer, not just those that have been integrated by Isis.

That said, Isis has a pluggable persistence API, so you could integrate to some other persistence mechanism by implementing to this API.

Embedded Runtime

Even if you choose to deploy on your own framework, you may want to explore Isis Embedded Runtime module. This allows the Isis metamodel to be instantiated standalone from the rest of the framework. Using this you could, for example, roll-your-own generic UI; or you could integrate with other UI frameworks (such as MetaWidget) that do a lot of the heavy lifting for you.