ObjectEntitytype. First create a protocol in the same manner that would be used for a corresponding Reactive entity.
EmployeeStatewill be read by the OR-Mapping
EmployeeRepositoryand set in the
EmployeeStatetype as the actual persistent object, and all mutations will be reflected in transitioning that type.
EmployeeStateto the database, use it's repository. Although we provide abstract bases of both
StatefulRepository, we can't do so for
ObjectRepositorydue to the numerous different ways that Object-Relational Mapping can be implemented.
SourcedEntitybase types, such as
CommandSourcedEntity. First create a protocol in the same manner that would be used for a corresponding Reactive entity.
ProductEntitydoes 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
ProductEntityand 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.
JournalProductRepositoryextends the Scooter
JournalRepositoryand implements the
StatefulEntitytype. First create a protocol in the same manner that would be used for a corresponding Reactive entity.
PersonStatetype as the actual persistent object, and all mutations will be reflected in transitioning that type. Note that the
PersonEntitydoes not emit domain events when it applies new state, although it is fully supported if the implementation uses events.
PersonRepositoryextends the Scooter
awaitin the repository implementation. This is to address the otherwise asynchronous nature of XOOM Lattice and XOOM Symbio. See the source of
StatefulRepositoryfor uses of
await(ReadInterest)returns the result of the
StateStore::read()once it has completed.
JournalRepositoryabstract base class to implement repositories for
SourcedEntitytypes that use Event Sourcing, Command Sourcing, or another type. You can see an implementation in the previous section.
StatefulRepository, we can't do so for an
ObjectRepositorydue 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.
BlockingMailboxfor 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.