And I mean, I could quibble, but let's roll with it.
Good luck getting finance to work with "event store-based spreadsheets", finding an "event store data lake" for your analysts, getting that other engineering team to also switch to an "event store"-based view of the world when they just want to query the system about a point-in-time about whether a user is up-to-date and aren't going to make another one for another month no matter what you do to your data store, so you'd better be right....
Event stores are an internal implementation detail, like whether or not you use Postgres or MySQL. They don't save you from the effects of changes and the parts of your state that leave your control. The example is well-chosen... billing state is going to leave your system, and the business forces causing it to leave your system are going to be powerful to the point that if you try to stand in front of them and yell "STOP! You all need to use an event store architecture if you want billing data!" that you will be fired and replaced.
Which is not to say that it's all hopeless. You can take care of the data well inside of your own domain. But as I know from experience, you're not freed from these forces just because you've got a good architecture. You really, really want to careful how you proceed forward, the moreso because nobody else working with billing data is going to be.
I'm responsible for the "usage based billing" portion of the billing system. I've often thought my primary contribution to the billing system hasn't been the usage based billing, but sitting in on the meetings as a senior engineer with a bunch of other people who are not engineers and whose programming teams are also busy with other non-engineering tasks, asking the right questions, and making sure that we get down to the true crux of the matter and find the exact right groups to do the right tasks with the right data coming from the right place, and making sure we don't get a whole bunch of workarounds from the wrong people sending the wrong data to do the wrong tasks, and then someone somewhere "just" "fixing" it later. Even when, and perhaps even especially when, the final task results in no action items for me or my team and all I did was ask the right questions, it is just so much easier when you don't make architectural mistakes in the first place in these cross-team decisions. Basically, using those requirements elicitation skills more than anything else.
My system basically is an event store. That doesn't so much solve the problems on its own, as keeps me flexible and able to respond to the other much less flexible systems as we work through problems.
And I mean, I could quibble, but let's roll with it.
Good luck getting finance to work with "event store-based spreadsheets", finding an "event store data lake" for your analysts, getting that other engineering team to also switch to an "event store"-based view of the world when they just want to query the system about a point-in-time about whether a user is up-to-date and aren't going to make another one for another month no matter what you do to your data store, so you'd better be right....
Event stores are an internal implementation detail, like whether or not you use Postgres or MySQL. They don't save you from the effects of changes and the parts of your state that leave your control. The example is well-chosen... billing state is going to leave your system, and the business forces causing it to leave your system are going to be powerful to the point that if you try to stand in front of them and yell "STOP! You all need to use an event store architecture if you want billing data!" that you will be fired and replaced.
Which is not to say that it's all hopeless. You can take care of the data well inside of your own domain. But as I know from experience, you're not freed from these forces just because you've got a good architecture. You really, really want to careful how you proceed forward, the moreso because nobody else working with billing data is going to be.
I'm responsible for the "usage based billing" portion of the billing system. I've often thought my primary contribution to the billing system hasn't been the usage based billing, but sitting in on the meetings as a senior engineer with a bunch of other people who are not engineers and whose programming teams are also busy with other non-engineering tasks, asking the right questions, and making sure that we get down to the true crux of the matter and find the exact right groups to do the right tasks with the right data coming from the right place, and making sure we don't get a whole bunch of workarounds from the wrong people sending the wrong data to do the wrong tasks, and then someone somewhere "just" "fixing" it later. Even when, and perhaps even especially when, the final task results in no action items for me or my team and all I did was ask the right questions, it is just so much easier when you don't make architectural mistakes in the first place in these cross-team decisions. Basically, using those requirements elicitation skills more than anything else.
My system basically is an event store. That doesn't so much solve the problems on its own, as keeps me flexible and able to respond to the other much less flexible systems as we work through problems.