Documentation

Start here

Find it by market role

makod registers the engine modules of the roles its [deployment] rollen declares, and a role-built processd cannot answer as a role it was not built for. Which principal may read which role's processes (§ 6a Abs. 1 EnWG) is the deployment's Cedar policy. makod, marktd, edmd, processd and agentd run in every role; the rest are role-specific.

How the layers fit together

graph TB
    subgraph transport ["Transport"]
        AS4["AS4 / ebMS3<br/>BDEW AS4-Profil"]
        API["API-Webdienste<br/>REST"]
    end
    subgraph format ["Format — generated from BDEW profiles"]
        EDI["edi-energy<br/>parse · validate · build"]
    end
    subgraph domain ["Domain — typed commands and events"]
        ENG["mako-engine<br/>workflows · Fristen · outbox"]
        MODS["mako-gpke · mako-wim<br/>mako-geli-gas · mako-mabis · …"]
    end
    subgraph services ["Services"]
        SVC["makod · marktd · billingd<br/>accountingd · edmd · …"]
    end

    AS4 --> EDI
    API --> ENG
    EDI -->|"typed message"| ENG
    ENG --- MODS
    ENG --> SVC
    SVC -->|"CloudEvents"| SVC

The domain layer never sees EDIFACT and the format layer never knows what a Lieferantenwechsel is, so a BDEW format release is an import of new profiles rather than a change to process logic.

Common tasks