Comments (3)
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.
Related Issues (20)
- A question about rich domain model which may not mentioned in book HOT 2
- Aggregate/Entity ids handling. HOT 2
- Issue with domain object not bounded to a Session HOT 12
- Question - Repository Pattern without UoW HOT 5
- [Question] Can we issue a command in a domain model?
- [Question] SqlAlchemy complete decoupling - is it possible? HOT 3
- [Request] Return types HOT 1
- Wrong url for event storming on Epilogue
- Ch7: mention a "compare-and-set" alternative to "repeatable read" HOT 1
- Making the message bus reliable HOT 3
- What comes after the allocation example? Or: how to modularize the event-driven architecture? HOT 2
- Adaptations for other programming languages? HOT 1
- [Question] A repository for every entity?
- the diagram is this book is very well HOT 1
- ch1: A confusion about unit test demo. HOT 1
- SQLAlchemy and Imperative Mapping (a.k.a. Classical Mapping) HOT 3
- Can we use async await HOT 3
- Book website is "broken" HOT 4
- 'Bug' in Chapter 9 with the `FakeUnitOfWorkWithFakeMessageBus` HOT 2
- You might want to make your favicon round and probably remove the underscore from the title HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from book.