Under the hood: the Go code DSB generates

Every claim about code ownership is worth exactly what the generated code is worth. So let's read some. When you model an Order entity with lines and a total, DSB writes a plain Go service:

// generated/internal/service/order.go
func (s *OrderService) Total(ctx context.Context, id int64) (Money, error) {
    lines, err := s.repo.LinesByOrder(ctx, id)
    if err != nil {
        return Money{}, fmt.Errorf("order %d: %w", id, err)
    }
    var total Money
    for _, l := range lines {
        total = total.Add(l.UnitPrice.Mul(l.Qty).Discount(l.DiscountPct))
    }
    return total, nil
}

No reflection soup, no giant runtime dispatching on strings, no annotations that only one vendor understands. Errors are wrapped Go errors; money is a typed value, not a float.

The shape of a generated project

• internal/model — structs mirroring your ERD, with validation derived from your field types;
• internal/repo — repositories over database/sql with plain, readable SQL and versioned migrations;
• internal/service — one service per aggregate, where workflow logic lands as ordinary functions;
• internal/http — handlers and routes for the React frontend, JSON in, JSON out;
• cmd/app — a single main.go that wires everything and builds to one binary per platform.

Workflows become functions

A visual workflow compiles to a Go function whose steps appear in order, with your script nodes inlined verbatim. Step through it in the studio or in any Go debugger — it is the same code.

Why this matters

Because one day you, or your successor, will open this project without DSB installed. They will find a Go module that builds with go build, tests with go test, and reads like a codebase written by a careful colleague. That is the whole point: the studio must earn its place every day — the code never holds you hostage.