Towards Three Fundamental Objects

The Question

When we look at a Board, we immediately see:

Board

Lists

Cards

Documents

This is the visual model inherited from Trello.

However, Alan Kay would likely ask a different question:

Which of these are actually autonomous objects?

In other words:

Which objects have their own behavior?

Which objects receive messages?

Which objects maintain their own state?

The answer may be much simpler than we think.

Document

A Document is unquestionably an object.

It has its own identity.

It owns its own history.

It evolves independently.

It can exist without any Board.

It understands messages such as:

Open

Edit

Publish

Comment

Preview

Documents are the primary knowledge objects of Seed.

Board

A Board is also an object.

Its purpose is to coordinate work.

It organizes Documents into a workflow.

It understands messages such as:

CreateList

AddCard

RemoveCard

MoveCard

FindCards

A Board has an independent lifecycle.

It can be shared.

Archived.

Replicated.

Query

Queries deserve to be first-class objects.

They are not filters.

They encapsulate behavior.

A Query understands:

Execute

Refresh

Filter

Sort

A Query continuously selects Documents.

Multiple AppViews may reuse the same Query.

Are Lists Objects?

Probably not.

A List has no meaningful existence outside a Board.

You cannot share a List.

You cannot replicate a List independently.

You cannot send messages directly to a List.

Instead, Lists are part of the Board's internal state.

When we send:

MoveCard(card, "Review")

the message is sent to the Board.

The Board decides how its workflow changes.

The List itself never receives a message.

Are Cards Objects?

This is the more controversial question.

The UI shows Cards.

Users manipulate Cards.

But are Cards really autonomous?

Perhaps not.

A Card may simply be the Board's representation of a Document.

When the user moves a Card, they are actually sending a message to the Board.

When they open a Card, the Board asks the Document to open.

The Card itself may have no independent identity.

It is simply how the Board renders one Document.

The UI Is Not the Domain

This is the key insight.

The user interface contains:

Board

→ List

→ Card

But the domain may actually contain only:

Board

↔ Documents

with Queries selecting which Documents appear.

Lists and Cards become implementation details of the Board's presentation.

A Different Way to Think About It

Instead of saying:

The Board owns Lists.

Lists own Cards.

Cards reference Documents.

We can simply say:

A Board organizes Documents.

Everything else is a user interface for that conversation.

Why This Matters

Reducing the number of fundamental objects simplifies the architecture.

Instead of designing interactions between many objects, we design a small society of autonomous objects that communicate through messages.

Documents manage knowledge.

Boards manage workflows.

Queries discover Documents.

Everything else is a projection of those conversations.

The interesting question becomes:

Can a Card receive a message independently of its Board?

If the answer is no, then it's probably not an object. If only the Board can interpret and act on card-related actions, then the Board is the object, and the Card is part of its internal representation.