Zum Inhalt springen
Nodary
Kostenlos starten

Vorlage für ein technisches Designdokument

Sechs verlinkte Dokumente, die ein System von den Anforderungen bis zum Rollout begleiten: der Kontext, die Architektur, Daten und Schnittstellen, wie es läuft und wie es ausfällt, und die verworfenen Optionen. Laden Sie sie als Markdown-Dateien herunter: Sie öffnen sich in jedem Editor, liegen im Repository neben dem Code, zeichnen ihre Diagramme auf GitHub und in Obsidian und lassen sich als Karte in Nodary importieren.

Vorlage herunterladenLive-Demo öffnen

6 Markdown-Dateien in einem .zip, 6 kB

Kostenlos, ohne Konto und ohne E-Mail-Adresse. Nutzen, ändern und teilen Sie sie, wie Sie möchten.

Technisches DesigndokumentKontext und AnforderungenArchitekturDaten und SchnittstellenBetriebAlternativen und Risiken

Lesen Sie jede Seite vor dem Download

Die Übersicht passt auf einen Bildschirm und verlinkt fünf Teile: Ein Reviewer liest die Zusammenfassung und geht dann direkt zu dem Teil, der ihn betrifft. Kursive Zeilen sagen, was hineingehört; die Beispiele folgen einem Beispiel-Feature, Freigabelinks, die ablaufen.

Dokumente

Datei Vorlage technisches Designdokument/Technisches Designdokument.md

Technisches Designdokument

So nutzen Sie diese Vorlage: Kursive Zeilen sind Hinweise. Ersetzen Sie sie durch Ihre eigenen Worte und löschen Sie sie dann. Werte in eckigen Klammern füllen Sie aus. Halten Sie diese Seite auf einem Bildschirm: Ein Reviewer soll daran erkennen, was er freigibt.

Auf einen Blick

FeldDieses Design
System oder Feature[Name]
Autor[Name]
Reviewer[Namen]
Status[Entwurf, in Prüfung, freigegeben, umgesetzt]
Anforderungen[Link zum PRD]
Ziel-Release[Datum oder Version]

Zusammenfassung

Drei Sätze: was Sie bauen, warum und die eine Entscheidung, die ein Reviewer zuerst ansehen sollte.

Beispiel (ein Beispiel-Feature): Freigabelinks bekommen ein optionales Enddatum. Jede Anfrage prüft das Datum, also funktioniert ein Link ab seinem Ende nicht mehr. Ein geplanter Job widerruft abgelaufene Links jede Minute; er räumt nur auf, ein verspäteter Lauf ändert für die Person, die den Link öffnet, nichts.

[Ihre Zusammenfassung]

Ziele und Nicht-Ziele

  • Ziel: [...]
  • Ziel: [...]
  • Nicht-Ziel: [...]
  • Nicht-Ziel: [...]

Der Rest des Designs

Jeder Teil ist ein eigenes Dokument. Verlinken Sie ihn, statt daraus zu kopieren, damit jede Tatsache an einer Stelle lebt.

Diese Vorlage dürfen Sie frei nutzen, ändern und teilen. Sie stammt von Nodary, wo sich diese Dateien als Karte verlinkter Dokumente importieren lassen.

Vorlage herunterladen6 Markdown-Dateien in einem .zip, 6 kB

So nutzen Sie sie

  1. Von den Anforderungen ausgehen

    Verlinken Sie die Produktanforderungen auf der Kontextseite und listen Sie die auf, die das Design prägen. Ein Design, das keine Anforderung erfüllt, ist ein verkapptes Refactoring.

  2. Erst zeichnen, dann schreiben

    Zeichnen Sie die Komponenten und die Aufrufe zwischen ihnen vor dem Fließtext. Reviewer sehen eine fehlende Box schneller als einen fehlenden Absatz.

  3. Aufschreiben, was Sie verworfen haben

    Tragen Sie bei den Alternativen die ernsthaft erwogenen Optionen ein. So öffnet das Review sie nicht einzeln wieder.

  4. Nach der Umsetzung aktualisieren

    Wenn der Code ausgeliefert ist, markieren Sie, was vom Plan abweicht. Wer danach kommt, liest das Design, um zu verstehen, wie das System funktioniert, nicht wie es gedacht war.

Als Karte in Nodary importieren

Nodary ist ein KI-nativer Workspace, in dem die Dokumente eines Teams verlinkt sind, statt sich zu stapeln. Importieren Sie die .zip, und das Design kommt mit seinen fünf Teilen darunter an, die Links bleiben erhalten und das Diagramm wird als bearbeitbares Mermaid-Diagramm gezeichnet. Reviewer kommentieren eine Passage oder ein Element eines Diagramms, die Autorin bittet um Freigabe, und Coding-Agenten wie Cursor, Claude Code oder VS Code lesen das Design per MCP, bevor sie den Code schreiben.

  1. Öffnen Sie die Karte eines Projekts und wählen Sie „Importieren“.
  2. Wählen Sie den Tab „Ordner oder ZIP“ und dann „ZIP wählen“.
  3. Wählen Sie die heruntergeladene Datei, prüfen Sie die Baumstruktur und importieren Sie.

Der Free-Plan bietet zehn Dokumente pro Workspace, die eigene Seite des Projekts eingerechnet: Die sechs der Vorlage lassen Platz für drei weitere. Nodary hat außerdem eine einseitige Vorlage für ein technisches Design eingebaut.

Cursor, Claude Code oder VS Code mit Nodary verbinden
Ein Projekt auf der Karte von Nodary: 43 Dokumente, gruppiert um acht Bereichs-Hubs, verbunden durch Hierarchielinien und benannte Links, mit den Zeigern der Teammitglieder auf der Karte; das gezeigte Beispielprojekt ist ein Spiel.

Ein Design schreiben, das Reviewer freigeben können

Ein technisches Designdokument scheitert, wenn Reviewer nicht wissen, was sie freigeben, oder wenn das beschriebene System nicht das ist, das ausgeliefert wurde. Diese Gewohnheiten verhindern beides.

Mit der Entscheidung beginnen

Sagen Sie in der Zusammenfassung, was Sie bauen und welche Wahl ein Reviewer zuerst ansehen sollte. Niemand sollte sie erst auf Seite drei finden.

Zeichnen vor schreiben

Ein Diagramm aus sechs Boxen und ihren Aufrufen ersetzt sechs Seiten Text und zeigt sofort das fehlende Teil.

Sagen, was Sie nicht tun

Nicht-Ziele halten das Review beim vorliegenden Design statt bei dem, das jemand lieber gelesen hätte.

Die verworfenen Optionen zeigen

Sagen Sie für jede wichtige Wahl, was Sie sonst erwogen haben und warum nicht. Reviewer diskutieren dann Ihre Gründe, nicht Ihr Ergebnis.

Für den Ausfall planen

Sagen Sie, was passiert, wenn jeder Teil ausfällt, wie Sie es bemerken und wie Sie sich erholen. Betrieb ist Teil des Designs, kein Anhang.

Nach der Umsetzung wahr halten

Markieren Sie, was sich während der Umsetzung geändert hat, und verlinken Sie die Entscheidungen dahinter. Ein Design, das zum Code passt, ist Dokumentation; eines, das nicht passt, ist eine Falle.

Fragen zum technischen Designdokument

Was ist ein technisches Designdokument?

Ein technisches Designdokument (Technical Design Document, TDD) beschreibt, wie ein System oder ein Feature gebaut wird, bevor der Code entsteht: Kontext und Anforderungen, Architektur, Daten und Schnittstellen, Deployment und Monitoring, Risiken und erwogene Alternativen. Entwickler schreiben es, damit andere den Ansatz prüfen, solange er sich noch günstig ändern lässt.

Was gehört in ein technisches Designdokument?

Eine Zusammenfassung mit Zielen und Nicht-Zielen, der Ist-Zustand und die Anforderungen, die Komponenten und wie sie miteinander sprechen, das Datenmodell und die APIs, Deployment, Monitoring, Sicherheit und Ausfallarten, die erwogenen Alternativen, die Risiken, der Rollout-Plan und offene Fragen. Diese Vorlage hat für jede Gruppe ein Dokument.

Was ist der Unterschied zu einem PRD?

Das Produktanforderungsdokument sagt, was das Feature leisten muss und warum. Das technische Designdokument sagt, wie das System es leistet. Schreiben Sie zuerst das PRD und verlinken Sie es dann im Design, damit sich jede Anforderung nachverfolgen lässt.

Wann braucht eine Änderung ein Designdokument?

Wenn sie mehrere Komponenten oder Teams betrifft, vorhandene Daten verändert, schwer rückgängig zu machen ist oder ein Risiko trägt, das ein zweites Paar Augen verdient. Eine kleine Änderung innerhalb einer Komponente braucht meist einen guten Pull Request, kein Designdokument.

Wer sollte ein technisches Designdokument prüfen?

Die Entwickler, die es bauen und betreiben, je ein Entwickler aus jedem betroffenen System und eine für Sicherheit zuständige Person, wenn es um personenbezogene Daten oder Zugriffe geht. Bitten Sie früh um das Review, bevor der meiste Code existiert.

Schreiben Spieleteams auch technische Designdokumente?

Ja. Die Vorlage für das Game-Design-Dokument hat einen Teil zum technischen Design für Engine, Zielplattformen und Pipeline; ein großes System wie Netzwerk, Speicherstände oder Tools verdient ein eigenes technisches Designdokument, verlinkt aus dem GDD.

Weiterlesen

Halten Sie das Design bei den Menschen und Agenten, die es bauen.

Importieren Sie die Vorlage in Nodary, und das Design wird zu einer Karte, die Ihr Team und Ihre Coding-Agenten lesen, bevor sie das System ändern. Kostenlos mit zwei Mitgliedern, einem Projekt und zehn Dokumenten, ohne Kreditkarte.

Kostenlos startenLive-Demo öffnenVorlage herunterladen