Decided I needed a bigger space to clarify my comments
It's clear there are four microservices,
I don't think that's clear at all.
It happens that this specific image comes from
https://github.com/cer/event-sourcing-examples
In the overview, Richardson writes:
One of the neat things about the modular architecture is
that there are two ways to deploy these four services:
monolithic-service - all services are packaged as a single Spring Boot executable JAR
Microservices - three separate Spring Boot executable JARs
accounts-command-side-service - command-side accounts
transactions-command-side-service - command-side money transfers
accounts-query-side-service - Account View Updater and Account View Reader
Presenting at Scala By the Bay, he calls out the pattern of one microservice publishing into an event store, and a second microservice subscribing to those events and updating a view store.
So I think you can make fair arguments for counting this as one, two, three, or four microservices.
One thing to consider in your counting is that the Account View Adapter needs to have an understanding in common with Accounts, and an understanding in common with Transfers, in order to understand the state information contained within the events to produce the view (the Account View Reader does not need this shared understanding, because it is just copying the data from the view store).
Udi Dahan has some interesting things to say about service boundaries; in particular, that you preserve loose coupling among your services by limiting the amount of data publicly shared by your services.
My application of his guideline to this diagram tells me that the Account View and the two aggregates must be part of the same boundary, because they all have access to the data which is private to this service.
Of course, you could still design these four service components separately, if you are careful to preserve backwards compatible changes to the event schema.
It's clear there are four microservices, but I don't understand becouse the "command side" microservices don't have their own database.
You could view those two microservices as having distinct logical event stores that happen to be the same physical store. There's some potentially headache involved if you decide that one of those logical stores needs to be migrated, but aggregate event streams are isolated from each other, so you don't need to worry to much about coupling between accounts and transfers.
And how should be the EventStore db? Single table? One table for each service ?
A typical relational schema for an event store will treat the event itself as a blob, and expose some of the meta data (the eventId, for instance) so that it can be joined with other tables. So a generic store probably looks like one table to hold the events, and another table to hold event streams. There are some links to discussions of relational schemas in storing events when using event sourcing.
If you wanted to partition/shard the schema that into multiple physical tables, you could do that too.
There are also non-relational stores that you might use. If you look into the details of Event Store (which is open source), you can learn a lot about how to implement a store.
Or you can just treat it as a black box.
