Skip to main content
One idea sits in the middle of Cordango: an application is a document rather than a codebase. You describe what the application is, and something else works out what it has to be to run. That document is the portable part. The platform runs it, and the standalone generator compiles it into conventional source code, both from the same file.
Everything above the App Definition is the open foundation. It’s Apache-2.0 and it runs offline: cordango check needs no model, no database, no account and no network.
Platform features need a Cordango workspace. Sign up here and create one in a few minutes.

See it in action

That pipeline is easier to see with real files. The expenses example is 14 files of YAML: one entity, three roles, three screens and an approval flow. On the right is what came out of it.
What a person wrote
What the generator wrote
The right column is an excerpt. The real build writes 103 files from 14.
The right side is the dotnet-vue target, which generates ASP.NET Core, EF Core, PostgreSQL, Vue 3 and Vuetify. It is one target. Another would produce something different from the same left column.
The entity became a class, a table configuration, a controller and a migration. The three roles became compiled permission rules. The lifecycle became a workflow the API enforces. Each screen became a page. It is ordinary source code and it is yours, but it is not where you make changes: edit the left column and generate again.

The things worth understanding

Semantic source

The .cordango.yaml files you write. One aggregate per file: an entity, a lifecycle, a role, a screen.

The App Definition

The single JSON document your source compiles into. What the app is.

The App Contract

Compiled beside it. What the app offers: its purpose, what it announces, what it accepts.

Apps working together

Point at another app’s records, or react to what it announces. Neither app is written for the other.

Forms

What a create dialog asks — only what is the person’s to say — and the forms people design inside a running app.

The schema

The formal gate. Why you should ask cordango vocabulary instead of reading it.

Targets

What turns a definition into a running application, and how each one declares its limits.

Workspaces and apps

A workspace holds many apps, and that’s on purpose. A company system is usually several applications that reference each other rather than one application with everything crammed into it.
Apps in one workspace can reference each other’s records, and they can reference core apps that the platform provides to every workspace.

Aggregates and scope

An aggregate is one addressable thing: an entity, a lifecycle, an action, an automation, a role, a screen. It’s the unit a file holds, and the same unit that --scope and cordango inspect work on.
The aggregate kinds are identity, domain, behaviour, access, screen and tab. They matter when you change an app through semantic operations, where --scope names the one aggregate a change may touch.

Coherent, complete, valid

Three words that get used interchangeably elsewhere. Here they mean different things.
error
The app doesn’t hold together. A reference points at nothing, a lifecycle names a state that doesn’t exist. Fix it.
normal
It holds together but isn’t a finished application yet: no screen to land on, nothing to create. This is the usual state mid-build. It publishes, with reasons printed.
a separate question
Whether one specific generator can build it. Ask with cordango check --target <id>.