Architekturmuster in Go: Wie man nicht in Goroutinen ertrinkt

Einleitung: Warum Architektur kein Luxus, sondern eine Notwendigkeit ist

Wenn Sie gerade erst anfangen, in Go zu schreiben, scheint alles einfach: Goroutinen fliegen, Kanäle summen und der Compiler erfreut mit Geschwindigkeit. Aber nach ein oder zwei Monaten verwandelt sich Ihr Pet-Projekt in ein Monster mit einem package main mit 3000 Zeilen und Gebeten „Hauptsache, es stürzt nicht ab“. Kommt Ihnen bekannt vor?

Go bietet leistungsstarke Werkzeuge, erzwingt aber keine starren Rahmen. Das ist sowohl ein Vor- als auch ein Nachteil. Ohne eine klare Architektur verlieren Sie sich schnell in Ihren eigenen Goroutinen. Genau hier helfen Architekturmuster in Go – bewährte Lösungen für typische Entwurfsprobleme.

In diesem Artikel analysieren wir vier Schlüsselmuster, die das Leben wirklich einfacher machen: Repository, Service Layer, Worker Pool und Pipeline. Sie sehen Codebeispiele, verstehen, wann welches Muster anzuwenden ist, und können sie sofort in Ihren Projekten einsetzen. Los geht's!

1. Repository Pattern: Geschäftslogik von der Datenbank trennen

Das erste Muster, das jeder Go-Entwickler beherrschen sollte, ist das Repository. Sein Kern ist einfach: Wir erstellen eine Zwischenschicht zwischen der Geschäftslogik und dem Datenspeicher (DB, Dateien, externe APIs).

Warum wird das benötigt?

\n
• Testbarkeit: Die echte Datenbank kann leicht durch einen Mock ersetzt werden.
\n
• Flexibilität: Umzug von PostgreSQL zu MongoDB? Nur das Repository wird geändert.
\n
• Sauberer Code: Der Handler weiß nicht, woher die Daten kommen – das ist die Aufgabe des Repositorys.
\n

Implementierungsbeispiel

Angenommen, wir haben ein Benutzermodell:

type User struct {\n    ID    int64\n    Name  string\n    Email string\n}

Wir definieren das Repository-Interface:

type UserRepository interface {\n    GetByID(ctx context.Context, id int64) (*User, error)\n    Create(ctx context.Context, user *User) error\n    Update(ctx context.Context, user *User) error\n    Delete(ctx context.Context, id int64) error\n}

Und seine Implementierung für PostgreSQL:

type PostgresUserRepo struct {\n    db *sql.DB\n}\n\nfunc (r *PostgresUserRepo) GetByID(ctx context.Context, id int64) (*User, error) {\n    user := &User{}\n    err := r.db.QueryRowContext(ctx, "SELECT id, name, email FROM users WHERE id = $1", id).\n        Scan(&user.ID, &user.Name, &user.Email)\n    if err != nil {\n        return nil, fmt.Errorf("get user by id: %w", err)\n    }\n    return user, nil\n}

Jetzt arbeitet Ihr Handler oder Service nur mit dem Interface UserRepository, nicht mit einer bestimmten Datenbank. Das ist das Architekturmuster Repository in Go in Aktion.

2. Service Layer: Geschäftslogik unter Kontrolle

Wenn das Repository für die Daten zuständig ist, dann der Service Layer für die Geschäftsregeln. Dieses Muster fasst verstreute Operationen zu sinnvollen Aktionen zusammen.

Problem ohne Service Layer

Ich sehe oft Code, in dem der Handler alles macht: die Anfrage validieren, Berechtigungen prüfen, in die DB schreiben und loggen. Das verstößt gegen das Prinzip der einzigen Verantwortung (SRP).

Wie behebt man das?

Wir führen eine Serviceschicht ein:

type UserService interface {\n    Register(ctx context.Context, name, email string) (*User, error)\n    GetProfile(ctx context.Context, userID int64) (*User, error)\n}\n\ntype userService struct {\n    repo UserRepository\n    mail MailSender\n}\n\nfunc (s *userService) Register(ctx context.Context, name, email string) (*User, error) {\n    // 1. Validierung\n    if name == "" || email == "" {\n        return nil, ErrInvalidInput\n    }\n\n    // 2. Geschäftslogik: prüfen, ob die E-Mail bereits vergeben ist\n    existing, _ := s.repo.GetByEmail(ctx, email)\n    if existing != nil {\n        return nil, ErrEmailAlreadyExists\n    }\n\n    // 3. Benutzer erstellen\n    user := &User{Name: name, Email: e