Bean SPIs

Our model entities separate more than public and private APIs. They also separate logic from state: they encapsulate state in plain beans and access it through nested interfaces.

For example, Codelist.Private implements its logic against a Codelist.Bean interface:

public interface Codelist ... {
  ...
  interface Bean ... { 
    ...
  }
  class Private ... implements Codelist { 
   
    ... 
   Bean state = state();
   ...     //state is in a Bean instance.
  }

}

State handling is factored out in traits. In fact, it is fully implemented in Identified.Private, where it is partly responsible for its parametrisation. All entity classes inherit from Identified.Private the method state() which return access to an instance of the bean interface.

#What's with the split?

The split logic-state scheme helps us keep entities persistence-ignorant, i.e. to implement domain logic independently from persistence technologies and persistence concerns. We can push these concerns down to a family of bean implementations.

In this sense, bean interfaces define an SPI for entities.

Currently, we have two bean families:

• memory beans, which remain transient.
• neo beans, which wrap over the graph nodes of a Neo4j store.

In the future, we may support other persistence bindings with additional bean families (e.g. a family with JPA annotations).

Of course splitting has additional memory costs. Effectively, it doubles the object count for the model. For a small-scale application running on modern JVMs, however, we estimated that memory allocation costs remain contained.