Commanded uses a GenServer process for each aggregate instance so that commands for the same bank account will be handled serially. As long as you guard against closing an already closed account in the command handler you will be fine.

One caveat is if you have multiple nodes hosting the application and you do not use distributed Erlang. In this scenario you could have two instances of the same bank account process running on two different nodes. If the same command was being processed concurrently on both nodes then they would attempt to write the same account closed event to the event store. To protect against this issue the event store uses optimistic concurrency when appending events to each stream. This ensures that the first write will succeed and the second write will be rejected since there is a new event in the stream. Commanded will apply the new event to the aggregate and retry the command which will now fail since the account has already been closed. You could also include the current version of the aggregate in every dispatched command and have it be rejected if the aggregate’s actual version when processing the command doesn’t match.

GDPR compliance with regards to PII (personally identifiable information) data can usually be solved in one of three different ways in an event sourced system:

1. “Crypto-shredding” where PII data is encrypted in events and the encryption key is thrown away to prevent read access to the data.
2. Store PII in a separate mutable data store which allows modification and deletion.
3. Allow events and/or streams to be modified (so not an immutable event store).

See [Recipe] GDPR compliance · Issue #4 · commanded/recipes · GitHub

Building an application which is fully event sourced is usually a bad idea, unless your intention is to learn the concepts involved. Event sourcing comes with some trade-offs such as accepting eventual consistency and requires more investment in modelling your domain over a typical CRUD based application. Therefore it’s better to use event sourcing where it is well suited: temporal models, complex business rules, auditability, etc.

It’s perfectly acceptable to mix CRUD and event sourcing within an application, but I’d recommend using a single style within each context.

Command handlers dont get to write to the event stream, they aren’t allowed. Command handlers have to ask an aggregate to actually do the command, and those aggregates serialize commands, meaning they run just one at a time. If a particular event sourcing library can’t guarantee serialized command handling for an aggregate, then it is a seriously flawed library. To my knowledge, Commanded does all of the right things there.

This does of course mean you need to choose your aggregates wisely, and understand how to run operations that involve multiple aggregates. To use your example, a bank account is a fine choice of aggregate, and the aggregate’s job will be to ensure that things like double closes don’t happen. Where things get tricky is something like a transer, wherein you want to move some funds from one aggregate to another. This tends to push things in a “TransferRequested” “TransferAccepted” style event log, which I actually think is pretty solid.

I’m not sure that these are common. If a library says it’s doing event sourcing, but it doesn’t provide a way to do serialized event handling around specific topics or aggregates, I’m not really sure it’s doing event sourcing. Certainly not CQRS.