Support chat for http://getprooph.org/ - official announcement: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html
Hey all, long time!
I'm designing a small quiz application that has a known structure: Categories, Series & Questions. Categories have 1 or more Series. Series has 1 or more Questions. You could start any Category or multiple and in any order (1, 4, 2, 3), but the Series inside the [started] Category are linear, as well as the Question inside the Series.
Again, for simplicity, we have a known structure.
This logic needs to be kept a bit abstract, in order to allow different "types" of quiz (i.e a single linear series of questions, with other hierarchy or something more complex like "if you answer A your next question is 5").
Scoring rules (for correct or incorrect answers and/or bonus for completion) might change for each instantiated Quiz.
For each user participating in the quiz, we need to store his state/progress including scoring his answers.
We need to be able to mark events such as:
Answer SubmittedAnswer Marked as Correct&Answer Marked as Incorrectto be able to provide the right feedback as the appropriateScore GrantedSeries Marked as CompletedCategory Marked as Completed
What is important here is to be able to determine at any moment the "next question" in each series as well as the states of each series (and the next available) & categories.
What I'm struggling a bit with is the modelling of the aggregates here - where would an answer be submitted to, who would the calculate the score (better yet, aggregate the scores) and how to maintain user-progress within the quiz.
For example: Would it make sense to have an QuizState aggregate that gets created when a new Quiz is started by a certain User and is responsible for all the above events? looks a bit too much responsibility, but I can't figure out how to properly split it...
Hello, I have legacy Symfony PSB + PEStore + PESourcing app, in AggregateRoot I have this:
$this->recordThat(
BookingWasSettledPartly::into(
$this->bookingId,
$newBookingId,
)
);
return $newBooking;$newBooking is added correctly but this event BookingWasSettledPartly is not, it used to work with older version but now it's not.
What is essential to make it work in this config (PSB+PES+PES)?
1 reply
btw. we've integrated prooph board Cody into Event Engine skeleton. You'll find the extended version here: https://github.com/proophboard/php-cody-engine-skeleton
$newBooking->recordThat(...)
This is my first implementation of an upcaster. The new event now has a new nullable property spotId. For old events null is added.
final class Upcaster extends SingleEventUpcaster
{
public function upcast(Message $message): array
{
if (! $this->canUpcast($message)) {
return [$message];
}
return $this->doUpcast($message);
}
protected function canUpcast(Message $message): bool
{
return $message instanceof TestResultReported;
}
protected function doUpcast(Message $message): array
{
if (array_key_exists('spotId', $message->payload())) {
return [$message];
}
/** @var TestResultReported $message */
$newMessage = TestResultReported::with(
$message->testId(),
$message->placeId(),
$message->placeName(),
null,
false,
$message->testResult(),
$message->testType(),
$message->testedAt(),
$message->guestId(),
$message->guestContactInformation(),
$message->acceptPrivacyPolicy(),
$message->reportedAt()
);
return [$newMessage];
}
}Is this the way to go?
Should I add a separate upcaster per event / aggregate root?
Thanks for the feedback. Could you elaborate on "do not base it on the event"?
For instance use a single upcaster for each transformation?
In our case - using the symfony bundles:
Prooph\EventStore\Plugin\UpcastingPlugin:
arguments:
- '@Trexxon\Common\Infrastructure\Prooph\EventStore\TestResultSpotUpcaster'
- '@Trexxon\Common\Infrastructure\Prooph\EventStore\TestResultMaybeV2Upcaster'
tags:
- { name: 'prooph_event_store.default.plugin' }Following this tweet by @gquemener I tried to implement an in-memory read model of a view model:
final class PgsqlEventStorePlaceDetailsFinder
{
private ProjectionManager $projectionManager;
public function __construct(ProjectionManager $projectionManager)
{
$this->projectionManager = $projectionManager;
}
public function detailsOfId(PlaceId $id): Details
{
$metadataMatcher = (new MetadataMatcher())
->withMetadataMatch('_aggregate_id', Operator::EQUALS(), $id->toString());
$query = $this->projectionManager->createQuery();
$query
->fromStream('place_stream', $metadataMatcher)
->when([
PlaceAdded::class => function ($state, PlaceAdded $event) {
$state = [
'accountId' => $event->accountId()->toString(),
'placeId' => $event->placeId()->toString(),
'name' => $event->name()->toString(),
'retentionTime' => RetentionTime::withDefaultDays()->toDays(),
'addedAt' => $event->createdAt()->format(DATE_ATOM),
];
return $state;
},
PlaceChanged::class => function ($state, PlaceChanged $event) {
$state['name'] = $event->name()->toString();
return $state;
},
])
->run()
;
$placeState = $query->getState();
return Details::fromArray($placeState);
}
}Thoughts?
I guess that would work.
You could also directly communicate with your event store (which is what the projection manager is most-likely doing) and remove some extra layers : https://github.com/gquemener/repositoring/blob/main/src/Infrastructure/Repository/Prooph/ProophEventStoreTodoRepository.php#L76-L101.
The idea being that in-memory synchronous implementation is enough until you encounter performance issue (I would advise to setup mecanisms to track this issue, if not already done).
You could also directly communicate with your event store
This is an older version of prooph where the query comes from the projection manager.
Here is an example of a newer version:
$eventStore
->createQuery()
->fromAll()http://docs.getprooph.org/event-store/standard_projections/overview.html
Is that what you suggested?
I'm suggesting to inject your Prooph\EventStore\EventStore service into your finder and use EventStore::load directly (check the link I shared for an example), instead of using the projection manager that is aimed to track the status of your projectors.
The reason being that your projector does not need to be tracked, because it reads all the relevant events from the start, every time.
That being said, what you did is probably working fine (however you're adding an unecessary overhead by querying the "projections" table, aren't you?).