--- id: 43 title: "Name your systems as archetypes, not machinery" status: current date: 2026-06-12 authors: - "Theo Zourzouvillys" tags: [architecture, design, culture, communication] references: - id: cutesy title: "Name your projects cutesy things — Nicole Tietz-Sokolskaya" url: https://ntietz.com/blog/name-your-projects-cutesy-things/ abstract: "A case for giving projects whimsical names instead of dry descriptive ones: a real name gives the work an identity people remember and rally around, and renaming later is cheap." - id: two-hard-things title: "TwoHardThings — martinfowler.com" url: https://martinfowler.com/bliki/TwoHardThings.html abstract: "Phil Karlton's famous line — \"There are only two hard things in Computer Science: cache invalidation and naming things\" — and its variations. Naming is hard because it is design, not labelling." - id: ddd title: "Domain-Driven Design — Eric Evans" url: https://www.domainlanguage.com/ddd/ abstract: "Evans's book introduces the 'ubiquitous language': a shared, rigorous vocabulary developed between engineers and the domain, used identically in conversation, documents, and code — because the language is the model." summary: "Names shape thought: a good name compresses a system's purpose, boundaries, and temperament into a word. Name the long-lived cast as archetypes — a Sentinel, a Seer — not Rule Engine and Decision Service. Bureaucratic names flatten judgment; a character must live up to its role." supersedes: null superseded_by: null aliases: [] --- ## TL;DR **Names shape thought.** In a complex system the name is the unit of reasoning: it stands in for behavior, purpose, and relationships everywhere the system is actually discussed — which is mostly in sentences, design docs, and incident channels, not in code. So name the **long-lived cast** of your architecture as **archetypes** — a **Sentinel** that oversees sessions, a **Seer** that reads signals for foresight, an **Oracle** that divines truth from the system's depths — not as machinery (*Rule Engine*, *Data Collector*, *Decision Service*). A vivid name is a working mental model **and a design constraint**: it encodes what the component is for, what temperament it has, and what it would never do — and it keeps you honest, because **every system must live up to its character**. Scope the practice deliberately: archetypes for the durable systems with real agency, plain descriptive names for plumbing — and write the cast list down ([ZFN-1](/zfn/1-engineering-decision-records/)) so the mythology is a shared language, not an in-group dialect. ## Context Naming is famously one of the [two hard things](ref:two-hard-things) — and it's hard because it isn't labelling, it's design. A name is the compression format for everything you know about a component: say it, and the listener decompresses behavior, boundaries, and relationships. Most architectural reasoning happens at exactly that altitude — "send this through X before we ask Y" — so the quality of the names bounds the quality of the conversation. The default drift, especially in serious domains — fraud, abuse, risk, trust — is toward bureaucratic language: *Rule Engine*, *Data Collector*, *Decision Service*. Those names feel safe and professional, and they flatten everything that matters. They're interchangeable; they describe mechanism, not purpose; and they hide the human truth that these systems **see**, **think**, and **judge**. A *Decision Service* sounds like it computes a value. What it actually does is pass judgment on a person. A sterile name lets you forget that; a name with weight doesn't. Take a fraud-and-abuse stack as the example, with human and mythic names for its components instead of sterile technical ones. The names aren't branding — they're semantic shorthand for intent and behavior; each embodies a role, a temperament, and a relationship: - A **Sentinel** doesn't *handle requests* — it *oversees sessions*, maintains order, and guards continuity. - A **Seer** doesn't *score inputs* — it *interprets signals* and offers foresight through patterns. - An **Oracle** doesn't *query data sources* — it *consults the depths of the system* to divine truth from complexity. This is the system-level version of DDD's [ubiquitous language](ref:ddd): the words you use in conversation *are* the model, so choose words that carry the model's full weight. It's also kin to the case for [cutesy project names](ref:cutesy) — a real name gives work an identity — but the point here is stronger than memorability: the name is doing **architectural** work. ## Recommendation **Give the durable cast of your architecture names with character — and hold each system to its character.** - **Name the cast, not the plumbing.** Archetypes are for the long-lived systems with genuine agency — the ones that see, decide, and act, and that people will discuss for years. A string formatter, a retry helper, an internal library: plain descriptive names. Mythologizing everything devalues the names that matter. - **Pick names that encode role, temperament, and boundary.** The test of a good name is that it tells you what the system would *never* do. A Sentinel doesn't predict; a Seer doesn't enforce. If the name can't draw that line, it's a label, not a model. - **Use the name as a design constraint.** When a proposed feature feels wrong for the character — asking the Seer to block traffic, asking the Sentinel to do statistics — treat that as a real architectural smell, not a poetry problem. Either the feature belongs elsewhere, or the system is quietly becoming two systems. A name with weight makes that drift visible early, and makes it harder to design carelessly ([ZFN-41](/zfn/41-choices-you-can-put-your-name-behind/) — names, like choices, carry accountability). - **Design as collaboration, not wiring.** Naming systems as characters in an ecosystem reframes the design question from "how do these components connect" to "how do these beings collaborate" — which is the right altitude, because it forces you to think in responsibilities, trust, and limits rather than in arrows between boxes. - **Stay in one register.** Pick a mythology — or at least a coherent voice — and keep new names inside it. A cast assembled from three unrelated fandoms reads as noise; coherence is what turns names into a shared language. - **Write the cast list down.** One page: name → role → temperament → what it never does. Keep it where your decision records live ([ZFN-1](/zfn/1-engineering-decision-records/)) and hand it to every newcomer on day one. The lexicon is what separates a shared mythology from an in-group dialect. - **Rename when the character no longer fits.** Systems evolve. When the Sentinel has grown a second unrelated job, either split it or rename it — a name that no longer tells the truth is worse than a sterile one, because it actively misleads. ## Consequences **Easier:** - Conversations compress: one sentence of cast-language carries what would otherwise need a diagram — behavior, hierarchy, and responsibility encoded in the names themselves. - Misfit features become visible early — "that's not the Seer's job" is an architectural review you can run in your head, before any code exists. - The systems that exercise judgment are named as things that judge, which keeps design and review honest about what's really being built. - Over time the cast becomes shared culture — a mythology that binds the team to its values, gives the work identity, and makes the architecture genuinely memorable. **Harder — and honestly:** - **Every newcomer pays an onboarding tax.** "Seer" tells you nothing until someone tells you. Without the written cast list this practice degrades into an in-group dialect that excludes exactly the people you most need to bring in. - **Discoverability suffers.** Nobody searching for "fraud scoring" finds the Seer. The lexicon, repo descriptions, and doc titles have to bridge archetype names to plain-language function, deliberately. - **Cuteness is a real failure mode.** Names chosen to be clever rather than true are branding, not modelling. The name serves the mental model — if you're picking names for the joke, you've inverted it. - **Names ossify.** A character that quietly outgrew its role misleads everyone who trusts the name. Renaming is awkward and has migration cost, and you have to pay it anyway. - Archetype names are internal shorthand. In external, legal, or customer-facing contexts you'll still need plain descriptions of what each system does — the mythology doesn't excuse you from explaining judgment systems in human terms. **New obligations:** - Maintain the cast list as a living document; it's part of the architecture, not decoration. - Treat names as reviewable interfaces: new names go through design review, and renames happen when the character changes. ## References - [Name your projects cutesy things](ref:cutesy) — the adjacent case for real names over descriptive ones; this note pushes it further: the name does architectural work. - [TwoHardThings](ref:two-hard-things) — naming is hard because it's design, not labelling. - [Domain-Driven Design](ref:ddd) — ubiquitous language: the words you reason in *are* the model. - [ZFN-1](/zfn/1-engineering-decision-records/) — where the cast list lives: legible, durable records the next person inherits. - [ZFN-41](/zfn/41-choices-you-can-put-your-name-behind/) — names, like technical choices, carry accountability; weight is the point. ## Changelog - **2026-06-12**: First published as a Field Note.