How to separate data and product layers

Naming the planes: data, product, interaction

Three planes cover most product architecture. The data plane holds what the system stores: tables, collections, files and the events that arrive. The product plane holds the logic that turns stored records into answers, such as services, rules, calculations and the model each screen reads. The interaction plane holds the screens and what a person can do on them.

Write the three names down before you touch the app, and add a name only once you have content for it. An empty plane is worse than a missing one, because a reader of the picture will assume there is something there. Four planes is comfortable, five is pushing it, and eight is the hard maximum.

The same split works for other subjects. A research project can be evidence, analysis and conclusion, and a business can be market, offer and operations. What matters is that the planes hold different kinds of thing rather than different steps in a sequence. The layers guide covers the general case.

• Data is what is stored, product is what is computed, interaction is what a person does
• Name a plane only when you have content for it
• Three planes suit most architectures and four is comfortable
• Planes are parallel kinds rather than a timeline

Moving the data layer to the back plane

Start with the data plane, because it is the most concrete of the three. Create a layer, name it Data, and move the branches that describe stored things onto it: an orders table, an event stream, a file store, a third-party feed. Each of those is one node with a few children, which is the right size for a card in the stack.

The depth order is something you set rather than something the app decides for you. The up and down buttons on a layer chip move that plane along the depth axis, and the nodes on it follow the plane, so you can put the data at one end of the stack and confirm it from the side camera.

Check the placement before you add the second plane. If the data plane is already crowded or thin, the fix belongs in the map rather than in the camera. Press 3 and 2 to move between the flat view and the stack, and the shortcut sheet has the full list of keys.

1. Add the layer. Use the plus button in the layer tab row, then name the new layer Data from the 3D rail.
2. Move the branches on. Select each stored thing in turn and use the arrow button on the Data chip to move the branch onto that plane.
3. Set the depth order. Use the up and down buttons on the layer chip to place the data plane at the end of the stack you want.
4. Look from the side. Press 3, pick the side camera, and check the data plane reads as one group rather than a scatter.

Putting the product layer in the middle

The product plane goes next, and the middle of the stack is the right place for it because it sits between what is stored and what a person eventually sees. Its nodes are the rules and the services: pricing logic, an eligibility check, a summary that joins two tables into one view.

Add a second layer and name it Product, then move the logic branches onto it. A branch that reads from the data plane and feeds the interaction plane belongs here, and the links you add later will make that explicit. Put the layer between the other two in the depth order, so the stack reads from one end to the other.

The interaction plane comes last, because it is the easiest to describe and the most likely to sprawl. Its nodes are screens and the actions on them, and a screen that pulls from three different services is one node with three children rather than three separate nodes.

• Product nodes are rules and services rather than screens
• Put the product plane between data and interaction in the depth order
• One screen with three sources is one node with three children
• Links in and out of the middle plane are the interesting ones

Note: A layer in the middle of the stack is where the links get interesting, because a link into or out of it crosses the depth axis. That is the part worth drawing well, and the part a flat map cannot show.

Linking a data source to the screen that uses it

Cross-links are what turn three planes into an architecture diagram. The Link button in the 3D rail starts link mode: click the source card, then the target card, and a tube is drawn between them that sweeps through the depth axis. A link from an orders table to an order summary card says exactly which screen depends on which table.

Keep the links few and specific. A handful of real dependencies, each one drawn between the two things that genuinely depend on each other, reads far better than a link from every node to every other node, and it is much easier to defend in a review. The cross links guide shows how to keep link use readable.

Link order follows the order of the argument: data to product first, then product to interaction. If you find yourself linking a screen straight to a table, that link usually means a service is missing from the product plane, and the fix is to name the service rather than to shorten the link.

• Link mode: click the source card, then the target card
• A link between planes is drawn as a tube through the depth axis
• Prefer a few real dependencies to a web of them
• A screen linked straight to a table usually means a missing service

Reading the connections with trace mode

Select a node and press T. Trace mode dims every card that is not part of the selected node's neighborhood and keeps the links in that neighborhood lit, so what remains on screen is the path from one card to the next, across planes, with the rest of the architecture grayed out behind it.

Use it as an audit rather than a decoration. Trace each service, look at the screens it reaches, and check that the path matches the design. A service that reaches three screens through a different route each time is a coupling worth talking about, and a screen that nothing reaches is a screen nobody has connected yet.

Trace mode follows two hops from the selected node, so a longer chain needs a trace started from a node in the middle of it. The 3D layer stack guide covers the camera and the trace mode together, because the two work best side by side.

• Select a card, then press T
• Everything outside the neighborhood is dimmed
• Trace each service and check the path to the screens
• Two hops is the reach, so start in the middle of a long chain

Exporting the layered picture for a review

When the picture is the point, export the 3D view as PNG. The PNG button in the Actions section captures the frame, the camera position and the explode value exactly as you see them, so you can choose the angle that makes the argument and then keep that image. It is the only export that shows the three planes together.

Set the view before you export rather than after. Use the stack camera for the general shape, the side camera when the separation between the planes is the message, and raise the explode slider until the links crossing the gaps are readable. Turn trace off for a general picture, and use a trace for a picture about one specific path.

Then write the caption yourself, because an image of an architecture does not explain itself. One line naming the three planes and one line naming the dependency you are pointing at is usually enough, and it saves a paragraph in the meeting.

• PNG is the only export that shows all the planes at once
• Set the camera and the explode value before you export
• Use a trace only when the picture is about one path
• Caption the image with the two lines that matter

Keeping the layers when you export the map

The picture is for the review, but the map is the work, so keep the layer structure in the formats that carry it. A multi-layer map round-trips through Markdown and OPML with a [layer:N] tag on each item, which means the planes come back when the file is imported again rather than collapsing into one flat list.

The .canv project file is the archive for the whole document, holding the canvas elements, the style, the mind map and the App Builder project together with the camera and the layout mode. If the architecture map and the screens it describes live in one project, that file is the one to keep and to back up.

Remember what the picture exports do not do. SVG and PNG exports of the map capture the layer you are looking at, so export each layer separately when you need them, and use the 3D PNG for the whole arrangement. Export formats differ between tools, so check what the person receiving the file will be able to open.

• Markdown and OPML carry a [layer:N] tag on every item
• The .canv file is the archive for the whole document
• SVG and PNG of the map capture one layer at a time
• Use the 3D PNG when the picture must show every plane

A checklist you can reuse

• The three planes are named and each one holds content
• Data, product and interaction are parallel kinds rather than steps
• The depth order puts the planes in the sequence you want to argue
• Every cross-link names a dependency that genuinely exists
• Trace mode was used on each service to check the path to the screens
• The exported PNG was taken from a deliberately set camera and explode value
• The map was also saved in a format that keeps the layer tags

Common mistakes to avoid

• Empty planes in the picture. A layer with nothing on it still shows up in the stack, and a reader will assume there is something there. Delete an empty plane rather than leaving it in the export.
• A link for every relationship. A diagram where everything is connected communicates nothing. Draw the dependencies that hold the design up, and leave the comfortable ones out.
• Treating the planes as a timeline. Data, product and interaction are parallel kinds of thing, not steps in a process. If the depth order implies a sequence, the picture argues something you did not mean.
• Exporting the flat map for a layered review. SVG and PNG exports of the map capture one layer, so a flat export cannot show the architecture you built. Use the 3D PNG when the arrangement is the point.
• Losing the layer tags on the way out. A map exported as a plain outline and re-imported loses its planes unless the format carries them. Markdown and OPML keep a [layer:N] tag per item, and the .canv file keeps everything.

Frequently asked questions

How many layers do I need for a data and product split?

Three usually covers it: data, product and interaction. A fourth is worth adding when one of the three has grown into two genuinely different things, such as stored records and streaming events. Eight is the maximum, and a map that needs more than that is usually a case for two maps.

Does a link from a table straight to a screen belong in the map?

Usually not, because the dependency runs through logic. A table that feeds a screen usually feeds a service first, so the link belongs between the table and the service, and between the service and the screen. A direct link often means the service has not been named yet.

Can I show this to a team that has never seen a 3D view?

Yes, and the exported PNG is the reliable version of that conversation. Set the camera and the explode value deliberately, caption the picture with the plane names and the dependency you are pointing at, and keep the flat map open for the questions that come next.

Will the layers survive an export and import?

Markdown and OPML round-trip a multi-layer map with a [layer:N] tag on every item, so the planes come back. Picture exports behave differently: SVG and PNG capture the layer you are looking at, and the 3D PNG captures the whole arrangement as an image rather than as structured data.

This guide is part of the 3d layer stack collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.