How models, objects, and files are organized in IOModel.
A model describes one product, system, or domain as a tree of objects. Models are registered in a root index and can be split into per-object files for clean diffs.
Project to model to object
| Level | File | Holds |
|---|---|---|
| Project | models.yaml | Registers models by name |
| Model | models/<model>.yaml | Root metadata and first-level objects |
| Object | models/<model>/objects/** | Object definitions and nested children |
Root index
# models.yaml
models:
example-saas: nullModel root
# models/example-saas.yaml
title: Multi-Tenant SaaS Platform
type: model
description: Reference architecture for a B2B SaaS product.
objects_schema: c4
objects:
actors: null
product: null
workflows: {}Schema choice
objects_schema selects the object vocabulary. Use a built-in id (c4,
kubernetes), your own custom schema, or a schema URL. It
determines which object types and properties are available.
Splitting objects into files
As a model grows, give each object its own file:
models/example-saas/objects/product/application/api_service.yaml
models/example-saas/objects/product/application/api_service/rest_router.yamlEach object file declares its children with objects::
title: API Service
type: microservice:service
objects:
rest_router: null
tenant_filter: nullConventions
Keep slugs stable
Slugs become part of object paths that links and routes depend on.
One concern per file
After the first level, prefer one object per file for readable diffs.
Choose a schema early
Set objects_schema up front so object types stay consistent.
Use clear, domain-specific names. The model tree is read by people more often than it is edited, so optimize for understanding.
Last updated on