Sounds a lot like a variant of Model-View-Controller, or more precisely, both this and MVC are probably instances of a slightly more general pattern.
What is here referred to as the central data store is the model.
The services are the views. Just like views, they do not hold onto any actual application data, that must be stored in the model.
The services must not communicate with each other, just like views (and controllers/ViewControllers) should not communicate with each other. Instead they communicate via the store, just like in MVC, where the model is updated and then the model notifies other views of changes.
(The last part is the one that a lot of the alleged implementations of MVC get completely wrong, leading to the problems that they then blame on MVC. Which then leads to them creating new patterns to "fix" the "problems" of MVC that would be solved by just implementing MVC correctly).
So yeah: good stuff. Nice to see how good architectural patterns are widely applicable.
What is here referred to as the central data store is the model.
The services are the views. Just like views, they do not hold onto any actual application data, that must be stored in the model.
The services must not communicate with each other, just like views (and controllers/ViewControllers) should not communicate with each other. Instead they communicate via the store, just like in MVC, where the model is updated and then the model notifies other views of changes.
(The last part is the one that a lot of the alleged implementations of MVC get completely wrong, leading to the problems that they then blame on MVC. Which then leads to them creating new patterns to "fix" the "problems" of MVC that would be solved by just implementing MVC correctly).
So yeah: good stuff. Nice to see how good architectural patterns are widely applicable.