ObjectEntity
ObjectEntity
type. First create a protocol in the same manner that would be used for a corresponding Reactive entity.Employee
protocol.EmployeeEntity
, the EmployeeState
will be read by the OR-Mapping EmployeeRepository
and set in the EmployeeEntity
.EmployeeEntity
uses the EmployeeState
type as the actual persistent object, and all mutations will be reflected in transitioning that type.EmployeeEntity
's EmployeeState
to the database, use it's repository. Although we provide abstract bases of both JournalRepository
and StatefulRepository
, we can't do so for ObjectRepository
due to the numerous different ways that Object-Relational Mapping can be implemented.Sourced
EntitiesSourcedEntity
base types, such as EventSourcedEntity
or CommandSourcedEntity
. First create a protocol in the same manner that would be used for a corresponding Reactive entity.Product
protocol.ProductEntity
does not use an internal state type, although it could. There is an internal constructor that is to be used only by the repository, although it must be public since the implementations of ProductEntity
and the repository are in two different packages. The "when"
methods, which mutate the internal state of the entity as each event is applied, are registered in the static initializer and dispatched to by the base class just as they are with the corresponding Reactive entity types.JournalProductRepository
extends the Scooter JournalRepository
and implements the ProductRepository
.await
in the repository implementation. This is to address the otherwise asynchronous nature of XOOM Lattice and XOOM Symbio. See Completes::await()
and JournalRepository::await(AppendInterest)
.StatefulEntity
type. First create a protocol in the same manner that would be used for a corresponding Reactive entity.Person
protocol.PersonEntity
uses the PersonState
type as the actual persistent object, and all mutations will be reflected in transitioning that type. Note that the PersonEntity
does not emit domain events when it applies new state, although it is fully supported if the implementation uses events.PersonRepository
extends the Scooter StatefulRepository
.await
in the repository implementation. This is to address the otherwise asynchronous nature of XOOM Lattice and XOOM Symbio. See the source ofStatefulRepository
for uses of await(ReadInterest)
and await(WriteInterest)
. The await(ReadInterest)
returns the result of the StateStore::read()
once it has completed.JournalRepository
abstract base class to implement repositories for SourcedEntity
types that use Event Sourcing, Command Sourcing, or another type. You can see an implementation in the previous section.StatefulRepository
abstract base class to implement repositories for StatefulEntity
state types. You can see an implementation in the previous section.JournalRepository
and StatefulRepository
, we can't do so for an ObjectRepository
due to the numerous different ways that Object-Relational Mapping can be implemented. You may follow one of the styles exemplified in Implementing Domain-Driven Design.send(Message message)
method of the BlockingMailbox
. The mailbox invocation that occurs first locks the mailbox queue, but without blocking another attempt to lock. The compare-and-set prevents blocking on any secondary deliveries. So a second, third, forth, etc., delivery on the same thread enqueues the message, and when it sees that access is already reserved, it simply returns. When the message deliveries (method invocations) unwind, the original access will see all additional messages enqueued and deliver them. This could go on for a long time without causing issues, as long as the stack is given the opportunity to unwind before the queue causes an out-of-memory condition.BlockingMailbox
for all future development. It is provided more as a learning tool, rather than a production worthy tool. Using it in production for most or all actors gives you no advantages over a normal blocking paradigm with direct method invocations. Instead, we suggest that you use the above blocking entity types since they take advantage of strengths of direct method invocations.