Domain model

An agent that implements a story invents names when nobody gives it any. Two stories later the same thing exists twice, under two names. The domain model decides once what the product is made of, and every story after it uses the names on that page.

Skill name: discovery-domain-model-atlassian. It reads the brief and the journeys.

How to start it

In a session that already has the journeys in it:

Let's work out the domain model next.
Start with the entities you see in the journeys.

In a new session, tell it where the pages are:

/discovery-domain-model-atlassian The brief and the journeys are at
<Confluence URL>. Let's work out the domain model.

What it works out with you

The starting point is what the personas actually handle in the journeys. The skill takes the nouns from there, so nobody starts at an empty diagram. Five rounds, in this order.

Note

The page also gets a diagram of the model, above the tables: every entity with its attributes, and the cardinalities on the lines. It is an image, so you can open it full screen and zoom in. The tables stay the place where the model really lives.

Entities

The skill shows you the candidates from those nouns, and together you decide which of them are real entities. The test: are there several of them, can you tell them apart, and do you refer to one of them on its own? Then it is an entity. A colour, a title or a timestamp is an attribute.

Two more questions follow, and both find what the journeys hide. Is an important entity missing that no journey mentions yet? Are two of these names the same thing?

The names are a question of their own. They are English by default, even when the pages are written in your language. The names end up in the code, and a schema in two languages costs you time forever.

Relationships

For every relationship: the two entities, a name, how many on each side, and the type. The skill does not go through every possible pair. With more than five entities that takes long and helps little. It proposes what the journeys show, and then it asks only what is still open. Can a B exist without an A? That is the difference between a loose relationship and a part of something. Is one of them a special case of the other? Then you have an inheritance.

Attributes

For every entity: what you have to store about it, and what makes a single one of them identifiable. For every attribute: a name, a type, and whether it is mandatory.

States

For every entity that has a status: the allowed values and the allowed transitions. For every transition: what starts it, what has to be true for it, who may do it, and what follows from it. “When a round is closed, its assessments can no longer be changed” is that kind of rule. Stories need rules like that, and a journey rarely spells them out. An entity without a status gets no state section. The skill does not invent a lifecycle just to fill the template.

This round is worth the extra minutes. One journey publishes something and another one deletes it. Those are two transitions on the same entity. If the values do not match, the stories that use them contradict each other.

Subject areas

The skill groups the entities into subject areas. An area is a part of the domain with its own words and its own reasons to change, and it owns its entities: only that area creates and changes them, the others only read them. Entities that change together belong together. Personal data marks a strong border: an area that holds none should stay that way.

You confirm each area on its own. A small product often has just one, and the skill says so instead of making up a split. Only journeys that are in review or agreed count. A journey that is still a draft gets an open point, not an area. In the diagram, every area is one band.

Where it lands

One Confluence page under the brief. It holds what the domain is about, the model, the subject areas, the entities, the relationships, the states, the enumerations, and the points that stayed open.

The page is not a build order, and that is on purpose. The model is a reference. It holds what the product needs, not what the first release has to store.

Next

The design brief, and after it the technical frame. The technical frame comes after this page on purpose: what you have to store decides which database you need, not the other way round.