FlowConsole .fc.ts DSL (Preview)

FlowConsole looks for files that follow the .fc.<ext> naming pattern by default, for example .fc.ts, and treats them as architecture model files. arch/eshop.fc.ts is one such file: it describes the intended architecture of the system in source code, using a C4-like notation rather than a separate diagram format.

In the current Preview, the primary authoring style is the runtime DSL used in the eShop example: entities are declared as typed object literals, and interactions are described with fluent flow methods.

This documentation uses the public sample as the source of truth:

• v-flowconsole-tech/eshop repository
• arch/eshop.fc.ts model file

What this documentation covers

This documentation is intentionally focused on the current Preview .fc.ts runtime DSL:

• the .fc.<ext> file pattern that FlowConsole treats as an architecture model by default
• typed object literals such as User, ComputerSystem, ReactApp, RestApi
• hierarchy through system and belongsTo
• flow descriptions through sendsRequestTo, then, getDataFrom, executesRequest, and inParallel
• connection semantics through ConnectionOptions.kind

Anatomy of the eShop model

The eShop sample follows a simple top-down structure:

const customer: User = { name: "Customer", description: "Online shopper" };
const admin: User = { name: "Store Admin", description: "Manages catalog and orders" };
 
const eshop: ComputerSystem = { name: "eShop Platform" };
const frontend: Container = { name: "Frontends", system: eshop };
const gateway: Container = { name: "API Gateway", system: eshop };
const services: Container = { name: "Backend Services", system: eshop };
const data: Container = { name: "Data Stores", system: eshop };
const messaging: Container = { name: "Event Bus", system: eshop };

The file first defines actors and top-level boundaries. After that it adds concrete applications, APIs, data stores, workers, and external services under those boundaries. The goal is to describe the planned architecture model in a form that can be versioned in the repository, reviewed in pull requests, and loaded by FlowConsole.

How FlowConsole reads .fc.ts as a model

FlowConsole extracts architecture structure directly from the file:

1. Typed declarations create nodes.
2. system and belongsTo create nesting and container boundaries.
3. Flow methods create edges and ordered flow steps.
4. inParallel keeps parallel branches in the same user flow.
5. ConnectionOptions.kind changes how the connection should be interpreted: sync call, async work, event publication, or dependency.

That means the file is not diagram source code. It is a readable, versioned architecture model for the intended system design, which FlowConsole can later visualize, share, and check against reality.

Example flow

The checkout sequence in eShop shows the main interaction style:

customer.sendsRequestTo(webApp, "checkout")
  .then(webApp).sendsRequestTo(apiGw, "POST /orders")
  .sendsRequestTo(orderingApi, "create order")
  .inParallel(
    () => orderingApi.sendsRequestTo(orderingDb, "INSERT order", { kind: "dependency" }),
    () => orderingApi.sendsRequestTo(orderEvents, "publish OrderCreated", { kind: "event" }),
    () => orderingApi.sendsRequestTo(basketApi, "clear cart")
  );

This one block already captures:

• the actor who starts the interaction
• the request path through UI and APIs
• a database write
• an event publication
• a side-effect on another service

Next steps

• Open the API reference for the exact entity types, fields, and flow methods.
• Open the eShop guide for a step-by-step walkthrough with placeholders for product screenshots.