An event-sourcing library with a focus on pure functions and protocols.
Calamity is structured similarly to Commanded, and it is a goal of this project to support Commanded components via structs implementing Calamity protocols.
Useful implementations of these protocols are not currently provided. Calamity only dispatches commands to the given aggregate and process manager stores, and you must provide the stores yourself.
This project is in the experimental stage; do not use it in production.
Using Calamity means implementing a few protocols and behaviors.
See test/support
for a simplified example of how to use this library in a single process.
To create an aggregate, use
the :aggregate
macro available in the main Calamity
module,
then implement the Calamity.Aggregate
protocol.
defmodule MyApp.BankAccount do
use Calamity, :aggregate
defstruct [
...
]
def new(id) do
...
end
defimpl Calamity.Aggregate do
...
end
end
To update and store aggregates, the Calamity.dispatch/5
function requires a struct implementing the Access
protocol.
Aggregates must be accessed by ID and return a struct implementing the Calamity.Aggregate
protocol.
Calamity uses Access.get_and_update/3
to transactionally update the aggregate in the store and return events.
This means that Calamity supports aggregates stored in GenServers as well as simple maps.
Read guides/plugins.md
for examples of aggregate and process manager stores,
as well as an over-simplified list store for events.
Events need no protocol, so you can use plain structs.
defmodule MyApp.Events.AccountCreated do
defstruct [
...
]
end
Commands must implement the Calamity.Command
protocol.
defmodule MyApp.Commands.DepositFunds do
defstruct [
...
]
defimpl Calamity.Command do
...
end
end
Process managers must use
the :process_manager
macro available in the main Calamity
module,
then implement the Calamity.ProcessManager
protocol.
defmodule MyApp.ProcessManagers.Transfer do
use Calamity, :process_manager
defstruct [
...
]
def new(pm_id) do
...
end
def interested?(event) do
...
end
defimpl Calamity.ProcessManager do
...
end
end
Active process managers are stored in a multi-level data structure that must implement the Access
protocol.
The first level maps modules to collections of process managers implementing that module,
and the second level maps IDs to specific process manager structs.
If you were to use Map
s, the process manager store would look like this:
%{
MyApp.ProcessManagers.TransferFunds => %{
"b0bda821-4bdd-4e27-ad95-f504b00a1282" => %MyApp.ProcessManagers.TransferFunds{id: ...}
}
}
Calamity uses Access.get_and_update/3
to transactionally update the process manager store and return commands.
This means that Calamity supports process managers stored in GenServers as well as simple maps.
Read guides/plugins.md
for examples of aggregate and process manager stores,
as well as an over-simplified list store for events.
Events are dispatched using Calamity.dispatch/5
.
Since Calamity uses pure functions and tries to minimize process count,
all components of the system must be passed to dispatch/5
,
and it will return updated versions of those arguments.
The arguments to dispatch/5
are:
- The command (implementing the
Calamity.Command
protocol) - The aggregate store (implementing the
Access
protocol) - An enumerable of process manager modules (that
use Calamity, :process_manager
) - The process manager store (implementing
Access
at two levels, see above) - The event store (implementing the
Calamity.EventStore
andCollectable
protocols)
This example is taken from Calamity's tests.
It is dispatching the RequestTransfer
command to an aggregate store containing two aggregates.
The Transfer
process manager is used, but there are currently no active process managers.
Last, the ListEventStore
is used to store and publish events.
Calamity.dispatch(
%Calamity.Commands.RequestTransfer{from: "1", to: "2", amount: 100, transfer_id: "asdfasdfasdf"},
%{
"1" => %Calamity.BankAccount{account_id: "1", name: "From account", balance: 100},
"2" => %Calamity.BankAccount{account_id: "2", name: "To account", balance: 0}
},
[Calamity.ProcessManagers.Transfer],
%{},
%Calamity.ListEventStore{}
)
This will return a tuple containing the updated aggregate store, the updated process manager store, and the updated event store.
{new_aggregates, new_process_managers, event_store}
This library does not implement its own event store or aggregate store.
If you're just getting started, use maps like in the examples, and wrap calls in a GenServer
to ensure sequential access.
Read guides/plugins.md
for examples of aggregate and process manager stores,
as well as an over-simplified list store for events.
This project was developed by Rosa Richter. You can get in touch with her on Keybase.io.
Questions and pull requests are more than welcome. I follow Elixir's tenet of bad documentation being a bug, so if anything is unclear, please file an issue or ask on the mailing list! Ideally, my answer to your question will be in an update to the docs.
Please see CONTRIBUTING.md for all the details you could ever want about helping me with this project.
Note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
MIT License
Copyright 2021 Rosa Richter
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.