Experiment 2: Aggregate with exposed queries

This post is second experiment described in post “Experiment: 10 Different implementations of Aggregate“.

This implementation assumed that aggregate is created from a projection of events. Aggregate is not aware of events or anything about event-sourcing. The responsibility of aggregate is to manipulate internal state and business logic.

The interesting part for me is about the separation of responsibility. Event-sourcing here is fully in the application layer and domain logic is not aware of any application details, even about events.

class Issue:
    id: IssueID
    version: int = 0
    _state: Optional[State] = None

    def create(self) -> None:
        self._state = State.OPEN

    def start(self) -> None:
        self._state = State.IN_PROGRESS

    def stop(self) -> None:
        self._state = State.OPEN

    def close(self) -> None:
        self._state = State.CLOSED

    def reopen(self) -> None:
        self._state = State.REOPENED

    def resolve(self) -> None:
        self._state = State.RESOLVED

    def can_create(self) -> bool:
        return self._state != State.OPEN

    def can_start(self) -> bool:
        valid_states = [State.OPEN, State.REOPENED]
        return self._state in valid_states

    def can_close(self) -> bool:
        valid_states = [
        return self._state in valid_states

    def can_reopen(self) -> bool:
        valid_states = [State.CLOSED, State.RESOLVED]
        return self._state in valid_states

    def can_stop(self) -> bool:
        return self._state == State.IN_PROGRESS

    def can_resolve(self) -> bool:
        valid_states = [State.OPEN, State.REOPENED, State.IN_PROGRESS]
        return self._state in valid_states

class IssueProjection:
    def __init__(self, event_store: EventStore) -> None:
        self.event_store = event_store

    def __call__(self, issue: Issue) -> Issue:
        for event in self.event_store.get(issue.id):
            self.apply(event, issue)
            issue.version = event.originator_version
        return issue

    def apply(self, event: Event, issue: Issue) -> None:
        event_type = type(event)
        if event_type == IssueOpened:
        elif event_type == IssueProgressStarted:
        elif event_type == IssueProgressStopped:
        elif event_type == IssueReopened:
        elif event_type == IssueResolved:
        elif event_type == IssueClosed:

class CommandHandler(Handler):
    def __call__(self, cmd: Command) -> None:
        projection = IssueProjection(self._event_store)
        issue = projection(Issue(cmd.id))
        self.process(cmd, issue)

    def process(self, cmd: Command, issue: Issue) -> None:

    def create(self, _: CreateIssue, issue: Issue) -> None:
        if not issue.can_create():
            raise InvalidTransition('create', issue.id)
        self._trigger_event(issue, IssueOpened)

    def start(self, _: StartIssueProgress, issue: Issue) -> None:
        if not issue.can_start():
            raise InvalidTransition('start', issue.id)
        self._trigger_event(issue, IssueProgressStarted)

    def stop(self, _: StopIssueProgress, issue: Issue) -> None:
        if not issue.can_stop():
            raise InvalidTransition('stop', issue.id)
        self._trigger_event(issue, IssueProgressStopped)

    def close(self, _: CloseIssue, issue: Issue) -> None:
        if not issue.can_close():
            raise InvalidTransition('close', issue.id)
        self._trigger_event(issue, IssueClosed)

    def reopen(self, _: ReopenIssue, issue: Issue) -> None:
        if not issue.can_reopen():
            raise InvalidTransition('reopen', issue.id)
        self._trigger_event(issue, IssueReopened)

    def resolve(self, _: ResolveIssue, issue: Issue) -> None:
        if not issue.can_resolve():
            raise InvalidTransition('resolve', issue.id)
        self._trigger_event(issue, IssueResolved)

    def _trigger_event(self, issue: Issue, event_class: Type[TEvent]) -> None:
        event = event_class(
            originator_version=issue.version + 1,

Reflections on this experiment

In the blog post “My structure for DDD component” you can see that I have two kinds of events. First is an aggregate event that has minimal data (or even no data at all). Second is the application event which is enriched with context data like command_id which triggered this event, Aggregate, timestamp of event, etc. Attributes that are useful for application but are not important for business logic. This experiment gave me the interesting idea that Events in the DDD component could be part of the application layer where IO is totally fine (like DateTime).

  • clear separation of Aggregate (Domain layer) from any details of application implementation (even event-sourcing technique)
  • events are fully in the application layer so there is no problem with enriching events with any additional attributes

source (Arkency version)

Be notified about next experiments

If you want to be notified join to my mailinglist.

I don’t spam!

Hi there 👋
It’s nice to meet you.

Sign up to join my mailing list.

I don’t spam!