Domain Objects vs. POJOs

There cases where your domain objects do not need persistence e.g. as they are stored in a external system and you access / modify them using a service interface. In this case you could model the domain either using Domain Objects («DomainObject») or POJOs (Plain old Java Objects, «POJO»).

From the modelling perspective there is actually no reason to use the one or the other. Modelling for both types is exactly the same. The only difference is the stereotype that is used to mark them.

From the code perspective also differences are not that big but you should be aware of them:

• Domain Objects
  Domain Objects will be sub classes of JEAF class com.anaptecs.jeaf.core.api.DomainObject. Domain objects are used to describe internal objects. So it would be considered to be bad style if you use them as part of a service interface.
  
  What is also important to mention is that domain objects always have a so called DomainObjectID. This ID can be used as an unique identifier.
  
  

• POJOs
  POJOs are, as the name says, just Java classes. They do not have a technical parent class or interface. It’s just a Java class. Of course if your model defines as base class for a POJO then this POJO will have this base class, but in general nothing will be generated which is not modeled.
  
  POJOs by default do not have an ID. If you like you can make use of stereotype «Identifiable». Then JEAF Generator will ensure that the marked POJO als implements interface com.anaptecs.jeaf.core.api.Identifiable and will have an ObjectID.