Sous le capot : le code Go que DSB génère

Toute promesse sur la propriété du code vaut exactement ce que vaut le code généré. Alors lisons-en. Quand vous modélisez une entité Order avec des lignes et un total, DSB écrit un service Go ordinaire :

// 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
}

Pas de soupe de réflexion, pas de runtime géant qui dispatche sur des chaînes, pas d'annotations que seul un éditeur comprend. Les erreurs sont des erreurs Go enveloppées ; l'argent est un type dédié, pas un flottant.

La forme d'un projet généré

• internal/model — des structs qui reflètent votre ERD, avec la validation dérivée de vos types de champs ;
• internal/repo — des repositories sur database/sql, du SQL lisible et des migrations versionnées ;
• internal/service — un service par agrégat, où la logique des workflows atterrit en fonctions ordinaires ;
• internal/http — les handlers et les routes du frontend React, JSON en entrée, JSON en sortie ;
• cmd/app — un seul main.go qui assemble le tout et compile en un binaire par plateforme.

Les workflows deviennent des fonctions

Un workflow visuel compile vers une fonction Go dont les étapes apparaissent dans l'ordre, vos nœuds script inclus tels quels. Parcourez-la pas à pas dans le studio ou dans n'importe quel débogueur Go — c'est le même code.

Pourquoi c'est important

Parce qu'un jour, vous — ou votre successeur — ouvrirez ce projet sans DSB installé. Vous trouverez un module Go qui compile avec go build, se teste avec go test, et se lit comme le code d'un collègue soigneux. C'est tout l'enjeu : le studio doit mériter sa place chaque jour — le code, lui, ne vous prend jamais en otage.