Journal
Praxis

Software gemeinsam gestalten: warum Fachleute die besseren Architekt:innen sind

24. Juni 2026· 7 Min. Lesezeit· Roy Carlitscheck
Beitragsbild · Praxis

Teil 1 der Reihe "Software gemeinsam gestalten". Sechs Beiträge darüber, wie wir Software mit den Menschen entwerfen, die sie nutzen.

Gute Software entsteht im Gespräch. Wer einen Ablauf seit Jahren verantwortet, versteht Zusammenhänge, Ausnahmen und Prioritäten besser als jede Anforderungsliste. Dieses Wissen gehört von Anfang an in den Entwurf.

Warum Fachleute früh eingebunden sein sollten

Softwareprojekte gelingen, wenn die fertige Lösung zum Arbeitsalltag passt. Das setzt voraus, dass die richtigen Fragen gestellt werden, solange die Richtung noch korrigierbar ist. Fachexpert:innen bringen genau das mit: ein Gespür dafür, welche Abläufe kritisch sind, wo die häufigen Ausnahmen liegen und welche Begriffe was bedeuten.

Binden wir sie früh ein, fließt ihr Wissen direkt in die Struktur der Software. Die Module spiegeln echte Zuständigkeiten wider, die Begriffe im Code decken sich mit denen im Gespräch, und Änderungen lassen sich dort vornehmen, wo sie fachlich hingehören.

Wie wir das umsetzen

  1. 01

    Gemeinsam modellieren

    In Workshops wie Event Storming erarbeiten Fachleute und Entwickler:innen den Ablauf zusammen an der Wand. Das gemeinsame Bild zeigt Lücken, Widersprüche und Prioritäten, die in keinem Lastenheft stehen.

  2. 02

    Fachsprache in den Code bringen

    Domain-Driven Design sorgt dafür, dass die Begriffe aus dem Workshop im Code landen. Wenn beide Seiten dieselbe Sprache sprechen, fallen Missverständnisse weg.

  3. 03

    Kurze Zyklen, echtes Feedback

    Alle paar Wochen sehen die Fachleute, was entsteht, und können die Richtung korrigieren. So wächst die Software entlang der echten Anforderungen.

Was das in der Praxis verändert

Teams, die ihren Entwurf gemeinsam erarbeiten, treffen bessere Entscheidungen über den Schnitt der Software. Jedes Modul hat eine klare fachliche Zuständigkeit. Erweiterungen betreffen einen abgegrenzten Bereich, weil die Grenzen entlang der Domäne verlaufen. Das spart Aufwand bei jeder späteren Änderung und macht die Software für neue Teammitglieder zugänglich.

Die besten Entwürfe entstehen dort, wo Fachexpert:innen und Entwickler:innen gemeinsam vor der Wand stehen.

Die Reihe im Überblick

In den folgenden Beiträgen vertiefen wir die Werkzeuge und Prinzipien hinter diesem Ansatz: Domain-Driven Design als Denkrahmen, Event Storming als Workshop-Format, Bounded Contexts als Brücke zur Architektur, die Ubiquitous Language als verbindendes Fundament und zum Abschluss DDD auf der Power Platform als Praxisbeispiel.

R

Roy Carlitscheck

Software Developer