Query/comment on chapter 05 version numbers about book HOT 3 CLOSED

Thanks for the feedback! I'm definitely less confident in chapter 5 than in earlier chapters, so it's good to have some other viewpoints.

Why would it need to assume that all products have changed? If a command is raised to allocate an order, or to add a batch, and the command completes successfully without raising an exception, then the system knows the product in question must have changed.

My preference here is definitely for the Aggregate to manage its own version number. The object in question is the only real arbiter of whether it changed or not. The prose is grasping at the idea that it might be tempting to find some magic way to set version numbers, but that's probably a bad plan, in the same way that we choose to make transaction boundaries explicit, even though it would be slightly simpler to automatically commit at the end of an operation.

To my mind, having the Aggregate control its version number makes the domain easier to reason about, since you know there's nothing else interfering with state elsewhere. It's not the system's job to know whether the domain has changed. That's why we have a rich domain model.

Later in this book mentions Event Store, which handles versioning for you, but maybe you see that as a problem?

No, if we were event-sourcing this aggregate, then I think it would be reasonable to rely on the event numbers as a source of the aggregate version since we know that they are aligned with our concurrency requirements.

In this instance, though, we don't have that option. We're generating a version number in our domain in order to achieve that same optimistic concurrency.

I take your point, though, and maybe we should look at the in-built support for versioning in SqlAlchemy

maybe made.com doesn't use Event Store for aggregates

Actually, for the most part we don't. We have a couple of event sourced systems, mostly used for orchestration, but in the general case we use Event Store as a persistent message bus and not as an event store in the event-sourcing sense.

from book.

I definitely agree that in a simple didactic example it's very likely that messing around with automatically updating properties on arbitrary objects in SQLAlchemy would be a bad idea. And even in production code simple is better than needlessly clever. I guess maybe what struck me was the wording that writes off setting version numbers outside the domain as pretty much impossible ("there's no real way") vs something that is possible, but comes with a whole bunch of extra complexity.

That extra complexity might be crazy ORM automagic, or it might be event sourcing, or it might be making every aggregate commands explicitly notify callers as to whether or not they've changed (by raising events for every successful command, returning a response object for every command, or some other means).

from book.

I guess maybe what struck me was the wording that writes off setting version numbers outside the domain as pretty much impossible ("there's no real way") vs something that is possible, but comes with a whole bunch of extra complexity.

Yeah, that's totally valid. I'll take a look at that wording.

from book.