Blog-Kategorie

Fachbeiträge zu Architektur

Alle Beiträge der devs group zu Architektur, neueste zuerst.

Architektur ist bei der devs group kein Schaubild, das nach dem Kickoff in einem Ordner verschwindet, sondern die Summe der Entscheidungen, die ein System zehn Jahre tragen müssen: welche Sprache, welcher Schnitt, welche Datenhaltung, welcher Betrieb. Die Beiträge in dieser Kategorie dokumentieren, wie wir solche Entscheidungen treffen und, mindestens so wichtig, wie wir sie festhalten, damit ein Team sie in zwei Jahren noch nachvollziehen kann.

  1. Architektur

    MCP-Server in Go produktiv betreiben

    Was die MCP-Spezifikation vom Juli 2026 ändert: Stateless Core, OAuth statt geteiltem Token, und die Tool-Design-Fehler, die wir am häufigsten sehen.

    Ralph Segi16 Min. Lesezeit

  2. Architektur

    Warum wir kritische Backends in Go bauen

    Nicht wegen der Benchmarks. Wegen dem, was ein Team nach drei Jahren noch versteht.

    Ralph Segi2 Min. Lesezeit

  3. Architektur

    Entscheidungen, die man in zwei Jahren noch versteht

    Architecture Decision Records sind das günstigste Werkzeug gegen Systeme, die niemand mehr erklären kann.

    Robert Pupel2 Min. Lesezeit

Worum es in dieser Kategorie geht

Konkret geht es um Architecture Decision Records als günstigstes Werkzeug gegen Systeme, die niemand mehr erklären kann, um die Frage, warum wir kritische Backends in Go bauen, und um Idempotenz als Grundlage jeder Zahlungs-API. Alle drei Themen stammen aus laufenden Projekten, etwa dem Broker-Backend für Relai oder den Systemen der Bundesverwaltung, nicht aus Lehrbüchern.

Wer die Denkweise hinter den Beiträgen im eigenen Projekt anwenden will: Auf der Seite Backend- und Frontend-Entwicklung steht, wie wir Individualsoftware bauen, und im Erstgespräch sagen wir offen, welche Architektur zu Ihrem System passt, auch wenn sie unspektakulär ist.

Der Massstab für jeden Beitrag hier ist derselbe wie für unseren Code: Er muss enthauptet überleben. Jeder Abschnitt beantwortet seine Überschrift im ersten Satz, jede Empfehlung nennt den Preis, den sie kostet, und wo eine Entscheidung vom Kontext abhängt, steht der Kontext dabei. Wer nur drei Minuten hat, liest die Einleitungen und weiss trotzdem, was wir empfehlen und warum.

Neue Beiträge der Kategorie entstehen, wenn ein Projekt eine Entscheidung erzwingt, die sich verallgemeinern lässt. Der schnellste Weg, nichts zu verpassen: der RSS-Feed des Blogs, oder alle paar Wochen ein Blick auf die Blog-Übersicht.

Wenn Sie in der eigenen Codebasis gerade vor einer solchen Entscheidung stehen, muss daraus kein Projekt werden: Ein Architektur-Review mit schriftlichem Befund ist oft in wenigen Tagen erledigt und beantwortet die Frage, ob das System die nächsten Jahre trägt oder ob ein Umbau ansteht. Den Rahmen dafür beschreibt die Seite Backend- und Frontend-Entwicklung; den kürzesten Weg zum Termin die Kontaktseite.

Und weil Architektur immer auch Betriebsentscheid ist, lohnt der Blick in die Nachbarkategorie Cloud & Infrastruktur, wo dieselbe Denkweise auf Cluster, Kosten und Upgrades trifft.

Denn am Ende ist jede Architektur nur so gut wie ihre Begründung im Moment der Entscheidung.

Gespräch statt Newsletter

Lassen Sie uns über Ihr System sprechen

Wenn Sie sich in einem dieser Artikel wiedererkennen, ist ein Gespräch der kürzeste Weg zu einer Antwort.

Jetzt sprechen