Given a very very simple twist on the canonical Ash Example, I just have a Ticket resource with only an id and name attributes backed by a postgres DB.

In the iex -S mix console, while playing around some more, and exploring a bit…

I execute the following code to create tickets; I see a series of INSERTs where each insert is in its own database transaction.

for i <- 0..5 do
  Helpdesk.Support.Ticket
    |> Ash.Changeset.for_create(:create, %{name: "Issue #{i}"})
    |> Helpdesk.Support.create!()
end

So, in a very loose analogy to DDD, the Ash Resource is akin to an Aggregate Root, where the Ash action also has the job to enforce the bounded context’s business rules of the Aggregate (or Resource).

And not to get sucked into the DDD arguments of whether or not the transactional boundaries must match consistency boundaries (the aggregate root), say I still want a set of action/changes to all succeed or not…

How is that achieved in Ash? How can I get a series of resources acted upon within the same DB transaction?

Like if I wanted something similar to a “DDD Service” that takes two resources and updates them conforming to a business rule, then persisting then in a “Unit of Work” ? – Loose analogies still.

For example, say I have two chess players (each a Resource/Aggregate instance) and I want to update their ranking after a game… I want to increase the winner’s points and decrease the loser’s points, while staying consistent?

Or am I thinking about this all wrong?

Thanks