The operation that can be invoked on a unit/module/class/etc that executes its principle objective and responsibility.
Applicative is similar to "application", as in "application logic". Because services are not applications, the term "application logic" is out of place when talking about service implementation. The term "applicative", as in "applicative logic" is more appropriately used in this case.
Autonomy is arguably the most critical quality of service design. It's the thing that can dictate whether you end up with a service architecture, or a web of web services organized as a distributed monolith. Autonomy is the quality that allows services to remain online when services that they communicate with become unavailable. Autonomy has the most profound influence on the design of services, the things that are inside of a service, and the things that are outside of a service. Without autonomy, services arguably aren't services at all.
A category is a group of streams all related to the same type of entity. An analogy would be a class in an object-oriented system.
A stream that contains the messages for every individual, identified stream in the category. For example, given the streams
account-456, the category stream,
account, contains messages from both individual streams in the account category.
A command is a message that represents an instruction sent to a component. A command is an input message. Commands are sent directly to components. They are a unidirectional transmission from one endpoint directly to another.
A package of code that represents a single business concern and/or business process, such as an account, a sale, and so forth. It's all the code wrapped around that concern to operationalize it. It has one or more entities, but very few. A component is often packaged as a RubyGem. A component is hosted either by itself or with other components in a service.
The component host is the outermost surface of an Eventide service. It runs right next to the operating system. It is the physical "service". It loads components into itself. It coordinates the threads that the consumers run on. It provides graceful shutdown for the components hosted in a service.
An endpoint is the source process that a message comes from or the destination process where it is sent. The term endpoint is often used informally as a substitute for service.
The entity is the core logic of the component. It's the domain model. It's analogous to a Rails model, but that's only an analogy. One entity's data is contained in a single, individual event stream. An entity collects any important information from the events in the entity's stream. It's also a data object. An entity has a corresponding projection, which is used to copy data from the events to the entity object, either by setting the entity's attributes or by invoking its methods. The data that an entity has collected is also used in handler code to determine whether a command should be processed.
When entities are retrieved via the entity store, they are cached in-memory, and, optionally on disk.
An entity's data comes from events. An event is a thing that has happened in a process, or it's a change that has been made to an entity's state. Often, these two are one and the same. The projection is a mechanism that receives events as inputs, and modifies the state of an entity. When an entity is "retrieved", its events are applied to it by the entity projection.
An entity snapshot is saved to disk (typically, in the message store) by the entity store as a performance optimization for warm-up time of the entity cache. The store saves a snapshot based on an assignable interval of events. For example, if the interval is set to 100, the store will save an entity's snapshot every 100 events that the store reads and projects onto the entity.
A stream that contains the messages for a single, identified entity. For example, a single account with the ID
123 has all of its events in its own stream, and that stream contains only the events for account 123.
The entity store is used to do the retrieval of entities. It coordinates a reader, an entity projection, and an entity cache. In reads only new events for an entity, projects them on to the cached entity, and updates the cache with the result of the projection. It may optionally record cached snapshots of entities to disk once every n events read and projected.
A message that represents the results and effects of some command having been processed. It's a record of something that has happened or that has been processed. An entity's state is gathered from the events that have been written about the entity. Each activity of an entity's life is recorded as an event, and written to the entity's stream.
Event sourcing is a style of entity storage that relies on reading entity data from a series of events that are recorded in a stream that holds the events for a single entity. An entity's data is stored by writing events to its stream. When the entity is "retrieved" from the entity store, the events are passed through an entity projection, which populates the entity's attributes.
One of the databases supported by Eventide. Event Store is an open source, special-purpose database designed specifically for high-availability event storage and event processing.
Event Store (Pattern)
A message is a data structure that represents either an instruction to be passed to a process (command), or a record of something that has happened (event) - typically in response to the processing of a command. Messages are written to the message store, and then read by consumers that then dispatch messages to handlers.
Message Queue and Message Bus
A form of message transport that relies on more elaborate mechanisms and protocols for moving messages through a system and keeping track of which messages have already been processed. These technologies are notably failure-prone and can cause subtle errors where messages are not delivered and the delivery failure can go undetected by operators, developers, and testers.
Unlike a message broker, a message store acts not only as a message transport, but also a durable store of messages that have been written. A service receives commands by reading new messages that have been written to the message store. Events are written to the message store in response to handling the inbound commands. Entity state is gathered from the event data that is written to the message store's message streams.
Any technology that is used to send (transport) messages from one process to another. For example: a queue, a broker, or a raw network transport protocol like TCP or HTTP.
Writes a message, or a batch of messages, to a single stream.
Provenance is the chronology of the custody or location of a historical object. It's used in the context of messaging workflows to describe metadata of preceding messages in a sequence of messages in a causal chain of messages.
In its strictest sense, a service is an autonomous unit of system operations that is made up of components that the service hosts.
A stream is the fundamental unit of storage that a message is stored in. When a message is written to the store, the writer must also be given the stream name that the event will be stored in. A stream is only stored in a single message store.
A stream's name not only identifies the stream, but also its purpose. A stream name is a string that optionally includes an ID that is prefixed by a dash (-) character. The part of the stream preceding the dash is the category, and the part following the dash is the ID. A stream with an ID is typically an event stream containing the events for the entity with that ID. For example:
account-123 is a stream for the account entity with an ID of 123. The
account stream name is the category stream name that contains all of the aggregated messages from all individual, identified account streams. See the overview of stream names in the user guide for more information.