The ERP Architecture Diagram: Seven Domains, One Local Stack

An enterprise resource planning system is hard to draw because it is wide. The tdk-erp-system example has seven business domains, each with its own backend services and a frontend, plus shared platform pieces. This article draws the whole layout in one Mermaid diagram.

The dashboard-to-API edges in the diagram come from dependsOn entries in the repo's service.json files. In the manifests I read, each of those dependencies sits inside one stack. The arrows from the developer and from the stacks to the platform are my simplification, not declared dependencies.

The diagram

flowchart LR
    DEV["Developer runs tdk up with a stack name"]

    subgraph PLAT["platform: shared infrastructure"]
        PDB["database-management: Postgres compose file"]
    end

    subgraph FIN["finance stack: 15 services in the README"]
        FAPI["backend APIs on ports 4010 to 4024"]
        FGL["general-ledger-api"]
        FAR["financial-analytics-api"]
        FDASH["finance-dashboard-app on port 3010"]
    end

    subgraph HR["hr stack: 12 services in the README"]
        HAPI["backend APIs on ports 4100 to 4111"]
        HEP["employee-portal-api"]
        HPORT["hr-portal-app on port 3020"]
    end

    subgraph INV["inventory stack: 18 services in the README"]
        IAPI["backend APIs on ports 4200 and up"]
        IMG["inventory-management-api"]
        IAPP["inventory-management-app"]
    end

    subgraph SALES["sales stack: 20 services in the README"]
        SAPI["backend APIs on ports 4300 and up"]
        SCRM["crm-api"]
        SAPP["sales-crm-app"]
    end

    subgraph MFG["manufacturing stack: 15 services in the README"]
        MAPI["backend APIs"]
        MPP["production-planning-api"]
        MAPP["production-control-app"]
    end

    subgraph SC["supply_chain stack: 12 services in the README"]
        SAPIC["backend APIs"]
        SCP["supply-chain-planning-api"]
        SCAPP["supply-chain-app"]
    end

    subgraph ANA["analytics stack: 8 services in the README"]
        AAPI["backend APIs on ports 4600 to 4607"]
        ABI["business-intelligence-api"]
        ABIAPP["bi-dashboard-app on port 3070"]
    end

    DEV --> FIN
    DEV --> HR
    DEV --> INV
    DEV --> SALES
    DEV --> MFG
    DEV --> SC
    DEV --> ANA

    FIN --> PLAT
    HR --> PLAT
    INV --> PLAT
    SALES --> PLAT
    MFG --> PLAT
    SC --> PLAT
    ANA --> PLAT

    FDASH -->|"dependsOn"| FAR
    HPORT -->|"dependsOn"| HEP
    IAPP -->|"dependsOn"| IMG
    SAPP -->|"dependsOn"| SCRM
    MAPP -->|"dependsOn"| MPP
    SCAPP -->|"dependsOn"| SCP
    ABIAPP -->|"dependsOn"| ABI

How to read it

The developer enters through one command, and each stack can be started on its own, such as tdk up finance. The platform folder holds a Postgres compose file (database-management). I have not checked how each stack connects to it, so the arrows from the stacks to the platform show a shared-infrastructure idea rather than a verified wiring.

Each dashboard depends on the API it calls, and the edge shows that dependency. The start order follows from it: the API starts first, then the dashboard. The dependsOn lists in the repo are the source of truth, so the diagram should be updated when they change.

The port blocks are visible in the names. Finance backends use 4010 to 4024, and HR starts at 4100. Analytics uses 4600 and up. Frontends sit in the 3000 range, with finance on 3010, HR on 3020, and analytics on 3070. Inventory, sales, manufacturing, and supply chain show their ranges more loosely, because I did not list every port for them in this article.

What the numbers say

The README gives 15, 12, 18, 20, 15, 12, and 8 services for finance, HR, inventory, sales, manufacturing, supply chain, and analytics. The manifest counts I took directly from the folders differ by one for several stacks, because a frontend and its backend may be counted differently. Check the folder before you rely on a single number.

What the diagram leaves out

It does not draw every service, every port, or every generated file. It shows the domain layout and the dependencies that the manifests declare. For a single stack, the stack walkthrough articles in the series show the services in detail.

Summary

The ERP example is seven domain stacks on one shared platform. Each stack has backends, a dashboard or portal, and dependencies declared in its own manifests. Start one stack at a time, and let the dependsOn edges decide the order inside it.