DCB Examples

[Midnighter]

In the following is my feedback to the DCB examples.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking.html#introduction-to-dcb

When querying for events in a DCB application, sequenced events are selected from an event store. The event store is given a query that has zero, one, or many “query items”. Each query item may have zero, one, or many “types”, and zero, one, or many “tags”. Optionally, the event store is also given a position in the sequence of recorded events after which events should be selected.

An event matches a query item if either the event’s type is mentioned in the query item’s collection of types or, if the query item has zero types, and then only if the event’s tags are a superset of the query item’s tags.

In this way, a query item with more types will be more inclusive, and a query item with more tags will be more restrictive.

Each query item will tend to add events to the set of events selected by the query. However, if a query altogether has zero types and zero tags, then all events will be selected, optionally after a given position in the sequence.

You linked to the general website before, but it might be more clear to specify that this follows the distinct specification laid out by dcb.events.

I was also considering whether a simple ER diagram may be helpful here.

erDiagram
    Query ||--o{  QueryItem : contains
    QueryItem ||--o{ Type : contains
    QueryItem ||--o{ Tag : contains

    Query {
        int after
    }

    QueryItem {
    }

Loading

Another way to formulate what you have written is that query items are combined by logical ORs, i.e., an event is selected if any of them matches. For one specific query item, the types are combined by logical ORs but the tags by logical ANDs.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking.html#introduction-to-dcb

After selecting a set of events from the recorded sequence, a command method will usually “project” the selected set of events into a “decision model”. The command method uses the decision model to make its decision, generating one or many new events, or raising an error.

I was wondering if command handler would be a better word, since method has a specific meaning.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking.html#introduction-to-dcb

The highest “last known position” at the time of the query is used when recording new events. Consistency of recorded state is maintained by using that sequence position, along with the same query items used for selecting events, to query for any other events recorded since the decision model was constructed.

I would guess that in 99% of cases, the append condition is indeed the same query, but it doesn't have to be.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking.html#enrolment-with-aggregates

This meets the “course subscriptions” challenge with event-sourced aggregates, without tricks and without accidental complexity. It shows that it is perfectly possible, entirely legitimate, and quite straightforward to extend the transactional consistency boundary when using event-sourced aggregates to include more than one aggregate. Indeed, this is a useful technique.

I agree that this example can be solved by appending an event to each aggregate's stream. And that also makes a lot of sense to me. I don't fully follow the obsession to record the fact of a student joining a course by a single event only.

Having said that, I do see that the option to select events from "multiple streams" in a single query is interesting. (In reality there is only one global stream when using DCB, but that is my mental image in the non-DCB paradigm.)

[d-m]

I didn't interpret the dcb.events link as saying that it was impossible to do the problem with event-sourced aggregates, merely that "In many contexts, it is impossible to update two Aggregates with a single transaction.".

The implementation here is clean, straightforward, and solves the problem, but does it in such a way that both aggregates can be changed in the same transaction. Would this approach work if they were in separate eventsourcing.Application subclasses, or separate processes?

[Midnighter]

If you use distributed applications of some form, I don't see that you can achieve anything other than eventual consistency. And you would need compensating actions.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking.html#testing-the-consistency-boundary

The meaning of “not less than” is “greater than or equal to”. It has been a common misapprehension that the “consistency boundary” notion in DDD is equal to one aggregate. The actual idea from DDD is that a database transactional consistency boundary must not be less than one aggregate. A consistency boundary that includes more than one aggregate, or indeed other things, has always been permitted by DDD.

I don't have exact sources readily available, but I read in multiple places that an aggregate protects the consistency of its own state.
Perhaps that is where the misconception comes from. Indeed, in your example it is the application that ensures the consistency of both aggregates. So the consistency is not ensured purely in the domain layer. (It works perfectly fine, of course.)

[Midnighter]

Perhaps the thoughts in this article apply also https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking-dcb.html#enrolment-with-dcb

        # Append using the same consistency boundary as the fail condition.
        self.recorder.append(
            events=[student_joined_course],
            condition=DCBAppendCondition(
                fail_if_events_match=consistency_boundary,
                after=head,
            ),
        )

I have a feeling that it should be possible to implement a smart retry mechanism, where events matched by the append condition are directly added to the sequence of events to build the state for the decision model.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking-dcb-refactored.html#test-case

My only comment to DCB 3 is essentially what you write here:

The extra steps also show that concurrent changes to enduring objects conflict with the student-course group, both for relevant events (such as changes to the ‘max_courses’ and ‘places’ numbers which are relevant when a student joins a course) but also for irrelevant events (such as changed to a student’s name). It would be possible to reconstruct enduring objects and groups with more restricted consistency boundaries, but then attributes that would be updated from events that are not included will have stale values. This aspect is remedied by using the “vertical slices” style that is shown in the next example.

You have basically abandoned the event types selection from the queries, which makes sense when hydrating whole aggregates.

Indexing definitely seems like a promising approach. Indeed, I've seen talk of not using explicit tags, but instead allowing indexing of any event property. I haven't seen an implementation for such a system yet, though.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking-dcb-slices.html#application

    def do(self, s: TSlice) -> TSlice:
        s = self.repository.project_perspective(s)
        s.execute()
        if s.new_decisions:
            self.repository.save(s)
        return s

I'm curious about the decision that execute does not return new events. Instead, you check the attribute new_decisions here, which seems a bit leaky.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking-dcb-slices.html#slices

class UpdateStudentName(Slice):
    def __init__(self, student_id: StudentID, name: str) -> None:
        self.id = student_id
        self.name = name
        self.student_was_registered: bool = False

    @property
    def cb(self) -> Selector:
        return Selector(types=[StudentRegistered, StudentNameUpdated], tags=[self.id])

    @event(StudentRegistered)
    def _(self) -> None:
        self.student_was_registered = True

    def execute(self) -> None:
        assert self.student_was_registered
        self.append(StudentNameUpdated(tags=[self.id], name=self.name))

I know, this is just an example, but since you already select StudentNameUpdated events, I would project those to get the current name and not append an event if the name to be set is the same as the current name.

[Midnighter]

https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking-dcb-slices.html#slices

Although I really enjoy the vertical slice example using DCB (as you can imagine), this query basically shows that I might as well have two projections built from events of separate event streams, one for the student and one for the course. The only differences being that I'd need two trips to the event store and append two events, one to each stream, as was done in the DCB 1 example.

    @property
    def cb(self) -> list[Selector]:
        return [
            Selector(
                types=[
                    StudentRegistered,
                    StudentMaxCoursesUpdated,
                    StudentJoinedCourse,
                    StudentLeftCourse,
                ],
                tags=[self.student_id],
            ),
            Selector(
                types=[
                    CourseRegistered,
                    CoursePlacesUpdated,
                    StudentJoinedCourse,
                    StudentLeftCourse,
                ],
                tags=[self.course_id],
            ),
        ]

[Midnighter]

Did you create a speedrun for https://eventsourcing.readthedocs.io/en/latest/topics/examples/coursebooking-dcb-slices.html#dcb-4-enrolment-slices? I'm curious if there is any noticeable difference to DCB 3?