Software architecture

A board for sketching a system: place typed components — services, stores, queues, scheduled jobs, third parties, clients — and join them with typed, labelled relationships. The type is the point. A component's KIND decides its shape, its tone, which sides a relationship may attach to, what it may attach to and what it may contain, so the board refuses to say things the vocabulary does not allow and tells you why in its own words: a store never calls a service, and an edge cannot attach to a compliance zone. Arrangement is content, not output — nothing is laid out for you, because a diagram where the datastores sit at the bottom and the third parties are pushed to one edge is saying something a computed layout would throw away. Relationships route orthogonally, leaving one side perpendicular and entering the other, and steer around components they have nothing to do with; drag a bend if you disagree. Cycles are legal, because a service that calls something that calls it back is a fact about the system rather than an error. Drop a component inside a boundary and it joins it; drag the boundary and its contents come along. What makes this a model rather than a drawing is Review, which reports what a person reading your diagram would ask about — a store nothing reads, a service nothing calls, a component dragged out of the boundary that still claims it, a relationship the vocabulary forbids. The vocabulary itself is data, so a process plant or an electrical one-line is a second catalog rather than a second app, and every control on this toolbar is built from whichever one is active.