vlingo/lattice
The vlingo/lattice component provides tooling for reactive Domain-Driven Design projects that are highly concurrent. The tools of the component include compute grid, actor caching, spaces, cross-node cluster messaging, publish-subscribe, CQRS, and Event Sourcing support.
Feature | Description |
​Grid​ | Provides an API for distributed computations and data processing across multiple nodes in a cluster. Supports distributed parallel processing by sending computational execution requests to actors on any node in a cluster with the potential to receive results in return. |
​CQRS and Persistence​ | Command-Query Responsibility Segregation uses two models per Bounded Context (application or service), the Command Model and the Query Model, otherwise known as the Read Model and the Write Model, respectively. ​ In addition, vlingo/lattice supports three styles of persistence, including Object, Sourcing, and Stateful. |
​Exchange​ | Provides an abstraction over Publish-Subscribe messaging exchanges or topics. This is a means to publish messages to exchanges/topics insides or outside your current application/service, and to subscribe to such messages. Provides translators from internal to external message types, and from external to internal message types. |
​Processes​ | Long-running processes that manage complex, coarse-grained, business transactions, must be managed through every step until completion. These tools assist in managing such processes whether by means of object persistence, stateful command models, or sourced with commands. |
​Routers​ | Use message-driven command routing to handlers that are responsible for modifying the domain model, which may be segregated as a Command Model. |
Provides an API for distributed computations and data processing across multiple nodes in a cluster. Supports distributed parallel processing by sending computational execution requests to actors on any node in a cluster with the potential to receive results in return.
Command-Query Responsibility Segregation uses two models per Bounded Context (application or service), the Command Model and the Query Model, otherwise known as the Read Model and the Write Model, respectively.
Provides familiar object-relational mapping capabilities by means of JPA and Hibernate, as well as very lightweight Jdbi mappings, over asynchronous persistence services.
Use Event Sourcing and Command Sourcing to represent the state mutations of the Command Model and Processes, respectively. Automated persistence reduces the architectural complexity of business-focused implementations.
In a typical object-based application or service that uses POJOs, for example, the lifecycle of Entities is different from that of actor-based Entities. Here we can assume that Entity and Aggregate as defined by DDD is interchangeable, as in what is described here deals with both concepts.
The following describes the typical lifecycle of a POJO Entity:
Non-existing Entity states are newly constructed and then persisted to storage
Preexisting Entity states are reconstituted from storage, modified, and then persisted back to the same storage
Across a single VM or a multi-VM cluster, there may be any number of the same Entity instances by unique identity, and thus the database must provide optimistic concurrency and detect concurrency violations via state versions
The object reference is released after Entity persistence and the instance garbage collected
The following describes the typical lifecycle of an actor-based Entity. Note that this applies across various types of Entities supported by vlingo/lattice, including Sourced<T>, StatefulEntity<T>, and ObjectEntity<T>:
Non-existing states are newly persisted, and persisted state is then reflected into the actor state
Preexisting states are possibly already in memory; if not in memory, states are reconstituted from storage; proposed changes are then persisted back to the same storage; following persistence, the state is then reflected into the actor state
Across a single VM or a multi-VM cluster, there is one entity instance by identity, and all requests for creation/modification will be focused on that single instance
The actor is retained in memory until memory constraints call for an least-recently used determination to indicate that this specific actor instance must be evicted to make room for other "hot" actors
I did attempt to support the constructor based approach. It leads to several very complex problems. I'll use your example to explain. (1) The MySourcedEntity constructor doesn't execute until after the Sourced constructor, so restoring state in the Sourcedconstructor is impossible unless forcing the MySourcedEntity and all other concrete entities to pass their id to the Sourced constructor. (2) Forcing 1 to work makes it extremely difficult to reconstitute the MySourcedEntity and all other concrete entities dynamically when the lattice detects a sent message but the actor is not currently in memory. (3) Even if forcing entities to pass their id to the Sourced constructor, think of what would be required to enable the following apply(...) to work. The Sourced constructor would have to make a blocking invocation to the Journal to recover state before returning to the MySourcedEntityconstructor to allow that apply(...) to work. Otherwise, returning to the MySourcedEntityconstructor immediately would enable the apply(...)to carry out prior to state recovery, or worse, simultaneously on two separate threads, doubt causing entirely crazy race conditions that would indeed be our problem to fix. (4) To avoid issues 1-3 we could pass in the existing lifecycle event stream to a constructor, but this assumes that we could safely perform an async fetch of the stream and then reconstitute the entity before another thread raced to accomplish the same, and thus at least duplicating instances in the cluster (or worse). (5) Attempting 4 would require more asynchronous components to load the stream and reconstitute the entity. This would likely lead to requiring both Application Service components and Repository components, such are found in the over-engineered N-tier architectures that vlingo is fighting against.
We could list another 2-3 undesirable outcomes of that design, but I hopefully you are already convinced that you really don't want it after all :)
One way to rethink this is that the constructor is really not a good expression of behavior and the Ubiquitous Language. Even when designing with POJOs it's generally desirable to hide the constructor behind an expressive Factory Method, such as follows:
Proposal proposal = Proposal.submitFor(client, expectations);
If you look at the vlingo-iddd-collaboration example you can see how this is done in all cases where a new EventSourced entity is being created:
Again inside ForumEntity: https://github.com/vlingo/vlingo-examples/blob/8fbc432545555641efab01d790183c6580a985c9/vlingo-iddd-collaboration/src/main/java/com/saasovation/collaboration/model/forum/ForumEntity.java#L57​
Again inside DiscussionEntity: https://github.com/vlingo/vlingo-examples/blob/8fbc432545555641efab01d790183c6580a985c9/vlingo-iddd-collaboration/src/main/java/com/saasovation/collaboration/model/forum/DiscussionEntity.java#L39​
I did since think of one possible way to make the constructor apply() work. I could cache the event(s) of the constructor's apply()to actually be performed following the completion of restore() under the control of start(). I haven't looked at it yet, but it probably would work. This would support any uses of apply()that occur prior to start(). A major caveat here is that MySourcedEntity may assume that it has no state currently (because we are in the same constructor used for initial state and pre-recovery, and the cached apply() may be wrongly performed following start() because the event(s) could be wrong given an eventually recovered state. Thus, even though I could find a way to support it, I still think it is ultimately the wrong feature to support.
The vlingo-lattice uses a LRU to evict actors from the lattice (grid) that have not been recently used. This would not happen to an actor that had just been created or reconstituted into the lattice.
Uses simple key-value storage with relational databases and NoSql storage to persist Command Model state, and which may also be used for Query Model state.
Using the modifications to the CQRS Command Model, project the record of mutations into the Query Model by means of reactive components.
Provides an abstraction over Publish-Subscribe messaging exchanges or topics. This is a means to publish messages to exchanges/topics insides or outside your current application/service, and to subscribe to such messages. Provides translators from internal to external message types, and from external to internal message types.
Long-running processes that manage complex, coarse-grained, business transactions, must be managed through every step until completion. These tools assist in managing such processes whether by means of object persistence, stateful command models, or sourced with commands.
Use message-driven command routing to handlers that are responsible for modifying the domain model, which may be segregated as a Command Model.
​
