Maybe this question is silly, but I'm a little confused about. Let's suppose we want leverage this pattern:
what exactly is the event storage scope in an enterprise application?
Does an event storage share among multiple processes, or is just an in-process concept?
What happens to events when the application close? Are they bound to an application "instance" or to an application?
What are the differences between an event storage and a MessageBus with Publisher/Subscriber ( a part the fact we can store the message history?
Who's responsible for the message idempotence?
what exactly is the event storage scope in an enterprise application?
The event store is just like a database in this sense. It isn't scoped by any given application. It can be scoped by business/linguistic boundaries however. For example if you partition your system into sub-systems, each sub-system can have its own instance of an event store.
Does an event storage share among multiple processes, or is just an in-process concept?
It is not an in-process concept. It is shared among processes/applications just like a database would be.
What happens to events when the application close? Are they bound to an application "instance" or to an application?
The event store would store all events that the application asked it to store. Events are keyed by a stream ID which is usually the ID of an aggregate root. This isn't bound to specific application instances.
What are the differences between an event storage and a MessageBus with Publisher/Subscriber ( a part the fact we can store the message history?
Storage of message history is basically the central difference in terms of functionality. The difference in use case is that a message bus is used to pass messages between endpoints where as an event store is used to persist messages (usually events).
Who's responsible for the message idempotence?
You as the developer. The event store views events as serialized data keyed by a stream, possibly with versioning. With versioning it can handle certain conflicts, but it is up to you to determine whether a message is idempotent or not.
I can't understand how breaking a transaction in several small pieces, even if all are transactional per-se can replace a distributed transaction.
Take a look at Clarifying the Saga pattern. The basic idea is that instead of grouping multiple operations under a single distributed transaction, the operation is broken into parts. If a certain part fails (which would cause a rollback in a distributed tx) an error message is sent which can allow interested parties to rollback operations. This can be seen as a form of compensation and it is a more natural way to analyse many business scenarios. For example, when a payment transaction is deemed invalid, it isn't deleted but a compensating transaction is added. This way of representing activity is in better alignment with reality because in reality rarely is something "undone".