How to model the eShop .NET sample with FlowConsole

Create a new model in your project

Open the target project and click New Model. In the creation dialog, enter a model name, keep the default meta-schema, and use the Git Settings section to point the model at the repository that contains the eShop example.

For this example, the important fields are:

• Repository URL: the clone URL of the eShop repository
• Branch: main
• DSL path patterns: arch/**/*.fc.ts

This gives FlowConsole a repository source and a narrow path scope for locating .fc.<ext> architecture model files.

Save repository credentials in model settings

After the model is created, open /models/:modelId/settings. In Git Configuration, confirm the repository URL and branch, keep Git Provider as Direct Git, and fill in Username plus Password / Token with the platform credentials that FlowConsole should use to access the repository.

Save the configuration before moving on.

Run the first Git sync

On the same settings page, click Sync Now. This pulls the repository source into FlowConsole and lets the platform load the .fc.ts model from the configured path pattern.

Wait until the sync completes successfully before opening the editor. If the sync fails, review the repository URL, branch, path pattern, and credentials first.

Open the eShop model in the editor

Open the model in the editor and keep arch/eshop.fc.ts visible. The important thing to verify at this stage is that the file is plain source code for the intended architecture model, not a separate proprietary diagram format. FlowConsole picks it up because it follows the .fc.<ext> naming pattern and treats it as a model file by default.

Read the model from top to bottom

The file starts with actors and system boundaries, then adds frontend apps, APIs, workers, data stores, messaging, and external dependencies.

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 services: Container = { name: "Backend Services", system: eshop };
const data: Container = { name: "Data Stores", system: eshop };

In the current Preview DSL:

• ComputerSystem defines the top-level system boundary.
• Container groups related applications and infrastructure.
• belongsTo nests concrete elements inside those boundaries.

Follow the main business flow

The checkout flow is a good example because it mixes sync calls, a database write, an event publication, and parallel branches:

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 pattern is the core of the Preview API: a flow begins at an actor, advances through then(...), and branches through inParallel(...).

Use sharing for read-only review

FlowConsole can create a public share link for a model. You can send this link to anyone, even if they do not sign in to FlowConsole. The shared page is read-only and opens directly on /share?token=....

This is useful when you want to review the model with engineers, product stakeholders, or external partners without giving them edit access to the workspace.