Hi Steven,
thank you for providing comprehensive comment as always, it’s very much appreciated!
The combination of “one monolith” with “several bounded contexts” doesn’t completely feel right, to be honest. When it comes to bounded contexts, you would typically have segregation of teams, repositories, databases, coding language, let alone what both those context’s their domain language (the messages) are.
In the target solution, when project reaches certain level of maturity, boundaries become stable and there’s a need to scale across several dimensions (delivery velocity, performance, maintainability), then yes, absolutely!
Here I’m working with a greenfield project, which is not even a real project to be honest, it’s more of an exercise where I’d like to start with modular monolith and evolve into the microservices gradually. This evolution is an important part of this exercise and I wouldn’t want to take a shortcut. That’s why I started with single instance of AxonServer, which simplifies infrastructure setup significantly and lets me focus on more interesting stuff instead. You noted correctly that eventually I’ll end up with multiple, isolated stores per context anyway, but unfortunately AxonServer EE is not an option for me. So I will rather have to choose MongoDB+Kafka option perhaps, which I’d like to delay a bit.
Used Typed Aggregate Identifiers which return a combined result of id+type on the
toString(). Regardless of whether you take this route through customizing thetoString()operation, I would recommend using a Typed Aggregate Identifier any how.
Using typed identifiers was on my TODO list anyway, so I decided to use this option for now, and seems to work fine!
Just wondering why aggregateType is not part of the unique constraint anymore (as of Axon 3)? To me, it seemed more natural that way. I’m guessing it might be because of performance reasons, especially that developers can always fall back to the typed identifier approach as you described above if needed. Was there any other reason?
Dealing with set-based-validation, to ensure an identifier is not accidentally used twice, would likely be necessary in this case
Regarding set-based-validation, I posted a question some time ago here, I’d appreciate your thoughts there as well when you have time.
Thanks again!
Beka