0080. An aggregate is a file; a concept is a value object; a repository is a pattern

0080. An aggregate is a file; a concept is a value object; a repository is a pattern

Status

Accepted. No row is open. DOM-31 is the operator’s ruling; the warning note attached to it is a lead reading, for operator review.

Rows: DOM-03, DOM-23, DOM-26, DOM-27, DOM-31.

Date

2026-10-11

Deciders

operator (Saulo Vallory), 2026-10-11 (DOM-03 at 06:40 and 07:07; DOM-31 at 09:16).

Context

Hyper’s Task and its Dependency rows form one consistency boundary, which Mesh cannot say today. The study (D13 and D17) asked how an aggregate is declared, whether value objects are a construct, and whether a repository is.

Decision

  1. An aggregate is declared in an aggregate file (DOM-23, option c). Its root is aggregate :Name; a root entity=Name line names the root entity; an entities section lists one part per line, each written as the entity’s name (DOM-03). A part with two links to the root names the one that ties it to the root with prop=: Dependency prop=:dependent. MX can let entities accept any tag name and read each as one tag. root Task was dropped because Mesh has no <tag> <Name> form anywhere: entity references are entity=Name.

  2. An aggregate contains concepts through its entities’ attributes (DOM-23).

  3. concept is a shared understanding of something with no identity, with as many fields as it needs (Country: name, abbreviation, population, flag, languages) (DOM-26). It is the same thing as a value object, so it is one construct; it replaces the study’s value.

  4. A repository is allowed as a pattern, and is no construct for now (DOM-27). A construct may come later.

  5. Mesh does not prevent an entity from being a part of two aggregates (DOM-31, ruled). Different views of the same tasks (Gantt, list, board) are read models, which may share entities freely.

    Lead reading, for operator review: the architecture rule (ADR-0084) may warn about an entity in two aggregates, the warning switchable off in architecture.mesh.mx, and it is never a build error. This note is not ruled.

work.mesh.mx (illustration)
aggregate :TaskAggregate
  root entity=Task
  entities
    Dependency prop=:dependent
    Comment

Options considered

D13 in the study: (a) a part-of flag on the belongs-to (recommended); (b) part-of=&rel on the entity line; © nothing. The ruling replaced them with the aggregate file (DOM-03, DOM-23), which is a new option the study did not list. D17: value and concept as separate constructs (rejected: one idea, two words), a single concept (chosen), nothing; repository: a construct or a pattern (chosen for now).

Trade-off analysis

A file puts the boundary in one place and lets a reader see a whole aggregate. It costs one more file kind and makes a Task’s boundary live apart from the Task. Allowing an entity in two aggregates keeps read models free and lets a project choose; a warning catches the mistake without forbidding the choice.

Consequences

  • No existing record is superseded. ADR-0057 is unchanged: an aggregate file sits in its module folder.
  • The concept tag has its own file under a concepts folder in the tag-discovery design (ADR-0085).
  • Aggregates and concepts are not built. No row dates them. RDM-01 applies: not before the port unless the port needs them, and as many planned constructs as possible before 1.0.

Action items

  • Syntax detail for entities (the MX side) and concept fields, when built.