Analysis

Business requirements

These goals explain why Gotion is being built instead of adopting an existing tool.

• BR-01 — Keep data in-house: Company policies or regulatory obligations may restrict where meeting notes, specifications, and customer data can be stored. Gotion therefore runs on infrastructure controlled by the adopting organization and makes no calls to external services at runtime.

• BR-02 — Keep costs independent of team size: Per-user pricing becomes expensive as a team grows, especially when many members only need read access. With Gotion, the organization pays for its infrastructure, not for each user it adds.

• BR-03 — Avoid vendor lock-in: Gotion stores content as Markdown, an open plain-text format, so that the content stays readable without Gotion. Using a proprietary format would recreate the dependency the project is intended to remove.

• BR-04 — Minimize administrative work: Gotion is intended for small companies and research groups without a dedicated system administrator. Installation, upgrades, and backups must be manageable by one part-time administrator.

• BR-05 — Make migration familiar: Teams already using Notion should not have to learn an entirely new way of working. Gotion must support familiar features such as nested pages, collaborative editing, and comments.

• BR-06 — Make the system auditable and adaptable: Gotion is released under the GNU General Public License v3. Organizations can inspect how it handles their data, modify it to meet their needs, and verify the privacy guarantees behind BR-01.

Event Storming

The domain was explored with an Event Storming session, following the ten steps taught in the course, after Alberto Brandolini and chapter 12 of Khononov. The process is iterative: the model is enriched one step at a time, and every step is shown below.

The board is on Miro: Gotion Event Storming. Each section below links to the frame holding the wall at that step.

The colour of a sticky is its meaning, not decoration. The legend is kept on the board.

The grammar reads read model → actor + command → aggregate → domain event for a human-driven slice, and domain event → policy → command → aggregate → domain event for an automated one. By the end of step 8 every command must be executed by an actor, triggered by a policy, or called by an external system. Actor and aggregate are both yellow and are told apart by size: the actor is the small sticky on its command, the aggregate the large one. Pain points are pink diamonds, and pivotal events are vertical bars rather than stickies.

Steps

1. Unstructured Exploration

Each team member wrote the domain events that can happen in the system on orange stickies, in the past tense, and put them on the board without any order and without worrying about duplicates.

2. Timeline

The domain events were organised in the order in which they occur in the business domain, starting from the happy path and branching out from there.

3. Pain Points

We went back over the timeline to spot the points that need attention: bottlenecks, manual steps, missing domain knowledge. They are pink diamonds placed on the event they concern, so that a debate never stalls the session.

4. Pivotal Points

The events where the context or the phase changes are marked with a vertical bar dividing the events before and after. They are the first indicator of bounded context boundaries.

5. Commands

The command that triggers each event or flow of events: light blue, written in the imperative, and placed before the event it produces. Where a person in a role issues it, a small yellow actor sits on the command.

6. Policies

The commands left without an actor are executed by an automation policy: an event triggers the command. Purple, worded when X then Y, between the event and the command it fires.

7. Read Models

The view over the data that an actor reads before deciding to execute a command: a screen, a report, a notification. Green, placed before the command.

8. External Systems

Pink: anything that is not part of the domain being explored, and that either issues a command in or is notified of an event out through a policy. No external system is in scope for Gotion. This step is also the completeness check of the method: by the end of it every command is executed by an actor or triggered by a policy.

9. Aggregates

Commands and events were regrouped into transactional consistency boundaries. Each aggregate is a large yellow sticky that receives commands on its left and produces events on its right. Eight emerged: User, Workspace, Workspace Membership, Page, Page Block Tree, Real-time Editing Session, Notification, Comment Thread.

Open step 9 on the board

10. Bounded Contexts

Finally the aggregates that belong together functionally were grouped, and a boundary was drawn around each group. Those groups are the candidate bounded contexts, and the candidate microservices.

Open step 10 on the board

The identified bounded contexts are:

• Account: who the user is, and the workspaces they work in (User, Workspace).
• Membership: who belongs to each workspace and with which role (Workspace Membership).
• Editing: the pages, their content and the real-time editing of a page (Page, Page Block Tree, Real-time Editing Session).
• Notification: what reaches the user (Notification).
• Discussion: the conversation attached to the content (Comment Thread).

They are candidates: the design weighs them against the subdomains and settles the bounded contexts in Strategic Design.

Open pain points

The pain points still open at the end of the session, each traced to the user story or quality attribute scenario it puts at risk. The architectural ones are settled in an Architecture Decision Record, the others in the domain model.

Ubiquitous language

Each word below has exactly one meaning, in this report, in the code, and in the API: a block is a Block in the source, never a Node or an Item.

This glossary records the ubiquitous language of Gotion. Following DDD, the language is split by bounded context: a term is precise only inside the context where it is defined, and the same person or thing can take a different name in each context. The terms come from the Event Storming board, where the sticky wording is the language, and from the user stories.

Account

Membership

Editing

Notification

Discussion

One person, many names

The same person takes a different name in each context, and each name carries only what that context needs.

Functional requirements

Expressed as user stories and grouped by the bounded contexts found with the Event Storming. Non-functional constraints on these behaviours are specified separately as Non functional requirements. Stories outside the current scope are kept aside, without an identifier, in Out of scope.

Account

• US-01 — Sign up and sign in: As a user, I want to register and authenticate with my email address and password so that I can access Gotion.
• US-02 — Manage workspaces: As a user, I want to create, rename, delete, and switch between multiple workspaces, and choose my main one, so that I can keep different projects or teams separate.

Membership

• US-03 — Manage workspace members: As a workspace Admin, I want to invite people to the workspace, remove members, and assign them the Admin, Editor, or Viewer role so that I can control who can read and who can change its content. A workspace always keeps at least one Admin.

Editing

• US-04 — Manage pages and blocks: As an Editor, I want to create, read, update, and delete pages and organize them and their blocks in a tree so that I can structure content hierarchically. Each workspace has exactly one root page, created with the workspace: it holds content like any other page, every new page is created inside it or inside one of its sub-pages, and it is deleted only together with the workspace.
• US-05 — Customize page metadata: As an Editor, I want to set a page title, icon, and cover so that pages are easy to recognize and personalize.
• US-06 — Edit Markdown blocks: As an Editor, I want to work with an ordered, nestable list of blocks so that content remains modular and structured.
• US-07 — Use native Markdown block types: As an Editor, I want to create formatted text, headings, bulleted, numbered, and to-do lists, and code blocks so that I can write rich content with Markdown.
• US-08 — Collaborate in real time: As a collaborator, I want to see the avatars of the other connected users and co-edit the same page so that we can work together.

Discussion

• US-09 — Discuss content in context: As a collaborator, I want to add comment threads to pages or individual blocks, resolve them, and mention a member of the workspace in a comment so that conversations stay connected to the relevant content.

Notification

• US-10 — Receive in-app notifications: As a user, I want to receive in-app notifications about invitations and mentions so that I can stay informed.

Out of scope for now

Stories written before the Event Storming and left out of the current scope, kept here so that the history of the analysis stays traceable.

Non functional requirements

Non-functional requirements, expressed as six-part scenarios (source, stimulus, artifact, environment, response, response measure). Each scenario is testable: the response measure is the acceptance criterion.

The reference deployment for every scenario is a single self-hosted node with 4 vCPU and 8 GB RAM, serving a workspace of 50 members, 10 000 pages and 1 000 000 blocks, unless a scenario states otherwise.

Performance

QA-01 — Editor input latency (constrains US-06, US-07)

QA-02 — Real-time propagation latency (constrains US-08)

QA-03 — Page open time (constrains US-04)

Availability

QA-04 — Process crash without data loss (constrains US-04, US-06)

Data Consistency

QA-05 — Concurrent edit convergence (constrains US-08)

Security

QA-06 — Unauthorized page access (constrains US-03)

QA-07 — Brute-force login (constrains US-01)

Deployability

QA-08 — Fresh self-hosted installation

Modifiability

QA-09 — Adding a block type (constrains US-07)

Accessibility

QA-10 — Keyboard-only and assistive-technology editing (constrains US-06, US-07)

Out of scope for now