← Back to the section

Picture this: a service has been in production for several years, processing orders or payments, maintained by three teams — and it has no description whatsoever. There's only the code. How do you make sense of what it does, and not break it when you make changes?

For that, Use Case Pattern has Level 0.

When there's no documentation, but the service already exists

In real projects it often goes like this: the service was written quickly, the documentation was put off until later — and "later" never came. A new developer spends weeks figuring out which tables relate to what, what statuses an order has, and where the limit on the amount comes from.

Level 0 solves exactly this problem: reconstruct a structured description of the service straight from the code — without meetings with analysts, without a business brief. We read the database migrations, the controllers, the tests, the configuration — and assemble a clear picture from that.

This isn't about "correct" architecture. It's about capturing things as they are — honestly and without embellishment.

What such a description includes

A level 0 description covers what's actually visible in the code:

  • Tables and fields — from the database migrations. Which entities are stored, what fields and statuses they have.
  • Entry points — HTTP endpoints, commands, message queues. What the service accepts from the outside.
  • Processing logic — what happens to the data: checks, computations, status transitions.
  • Integrations — which external services are called, which events are published to the broker.

Anything not expressed in the code — for example, who initiates an operation or what maximum response time is acceptable — is marked explicitly: not-declared. It's an honest signal: "we didn't find this, it needs clarifying".

Such a mark is more useful than an empty space: it shows where the description has gaps.

Why you need it

An as-is snapshot gives three practical benefits.

Fast onboarding to the service. A new team member reads the description and understands the structure in an hour — instead of two weeks of reading code.

A starting point for changes. Before changing anything in an old service, it's useful to capture the current state. Then you can see what you're starting from and what exactly you're changing.

A basis for an audit. When a description exists, you can also see what's missing: non-obvious dependencies, duplicated logic, forgotten endpoints.

How the specification is produced

The ucp-spec-tier-0 skill reads the service's sources and assembles a description in the standard format: a context root file plus one file per domain unit (aggregate).

Important rules the skill follows:

  • Only facts from the code. The skill doesn't assume or invent. If an aggregate isn't expressed explicitly, the description will have a table, not a "possible aggregate".
  • No "right/wrong" judgment. The goal is to capture, not to critique. Critique comes later, once there's something to build on.
  • level: 0 in the frontmatter — to distinguish a snapshot from a design description.

Where to go next

Level 0 is a starting point, not a final state. Next the team:

  1. Reads the description and agrees on what the service should really do.
  2. Replaces not-declared with real business facts.
  3. Moves the description to the target level: 1 Layered, 2 Use Case Pattern, or 3 DDD + Hexagonal.
  4. Gradually brings the code in line with the new description.

This order helps avoid a situation where refactoring starts without understanding what exactly is changing.

In short

  • Level 0 is a description of a service reconstructed from the code, when there's no documentation.
  • It includes tables, endpoints, logic, integrations — everything visible in the sources.
  • What's not in the code is marked not-declared rather than simply skipped.
  • The ucp-spec-tier-0 skill assembles this description automatically.
  • Level 0 is a point of departure from which you move toward the target architecture, not a final goal.

Further reading