Was Domain-Driven Design für euer Projekt bedeutet
Ein Fachmodell ist eine schriftliche Beschreibung, welche Dinge es in eurem Geschäft gibt und was mit ihnen passieren darf. Zum Beispiel: Es gibt Kunden, Aufträge und Rechnungen, und ein Auftrag wird erst abgerechnet, wenn er abgenommen ist. Ein Ticket beschreibt dagegen eine einzelne Änderung. Es sagt, was diese Woche anders werden soll. Welche Regel dabei gilt und welcher Zustand nie eintreten darf, steht dort nicht.
Domain-Driven Design ist der Name für diese Reihenfolge. Erst das Modell, dann der Code. Daran hängt für euch dreierlei. Wann Änderungen frei sind. Wo eure Regeln liegen. Und was ihr am Ende in der Hand haltet.
In einem Ticket steht nur die Änderung
Nehmt eine Belegkette. Aus einer Anfrage wird ein Angebot, daraus ein Lieferschein, daraus eine Rechnung, und am Ende steht vielleicht eine Mahnung. Jeder dieser Schritte ist ein Zustand, der falsch sein kann. Eine Rechnung ohne Lieferschein. Eine Mahnung auf eine längst bezahlte Rechnung. Zweimal dieselbe Belegnummer.
Das Ticket dazu heißt „Mahnlauf einbauen“. Es sagt, was gebaut werden soll. Es sagt nicht, dass eine bezahlte Rechnung keine Mahnung bekommt. Diese Regel kennt jemand im Team, und solange er da ist, fällt niemandem auf, dass sie nirgends steht.
Ein Fachmodell hält genau das fest, bevor jemand baut. Es nennt die Dinge eures Geschäfts, ihre Beziehungen und die Zustände, die sie annehmen dürfen. Es ist kein Konzeptpapier, sondern die Vorlage, aus der die Anwendung entsteht.
Regeln gelten im ganzen System, Aufgaben gelten einmal
Eine Aufgabe ist erledigt, wenn sie erledigt ist. Eine Regel gilt weiter. Sie gilt im Formular, im Import aus einer anderen Software und in dem Knopf, den jemand nächstes Jahr einbaut.
Wird jede Aufgabe für sich gebaut, landet dieselbe Regel an mehreren Stellen im Programm. Beim ersten Mal fällt das nicht auf. Beim vierten Mal ändert jemand drei davon und übersieht die vierte, und ab dann stimmen eure Zahlen an einer Stelle nicht mehr.
Steht die Regel im Modell, gibt es sie einmal. Die Struktur des Programms folgt dann eurem Geschäft und nicht der Reihenfolge, in der die Aufgaben hereinkamen. Durchgesetzt wird sie dort, wo die Daten liegen, und nicht in jeder Oberfläche noch einmal von Hand.
Größere Geschäfte lassen sich dabei in Bereiche teilen, die je eigene Regeln haben. Bestellung, Katalog und Abrechnung müssen nicht dieselbe Sprache sprechen. Sie müssen nur sauber aneinander anschließen, und wo das passiert, gehört ins Modell.
Domain-Driven Design ist der Name für diese Reihenfolge
Domain-Driven Design ist keine Technik und kein Werkzeug, das man einkauft. Es ist eine Reihenfolge. Zuerst wird beschrieben, wie euer Geschäft funktioniert, danach entsteht daraus die Struktur des Programms.
Für euch als Auftraggeber zählt daran vor allem eines. Ihr könnt das Modell lesen und prüfen, ohne eine Zeile Code zu verstehen. Es steht in euren Wörtern, nicht in unseren. Wer es liest, sieht sofort, ob wir euer Geschäft verstanden haben.
Nötig wird diese Arbeit überall dort, wo ein falscher Zustand echten Schaden macht.
- Rollen und Rechte, also wer was sehen und ändern darf
- Zustände und Freigaben, etwa ein Auftrag, der abgenommen sein muss
- Geld, also Zahlungen und Abrechnung
- Anbindungen an andere Software, die zusammenpassen müssen
Das gilt auch dann, wenn bei euch längst etwas läuft. Die Regeln stecken dann im alten Code, und aufgeschrieben hat sie nie jemand. Sie wieder sichtbar zu machen ist dort der erste Schritt und nicht der letzte.
Am Modell ist eine Änderung frei, im gebauten System kostet sie
Einen Satz auf Papier zu streichen kostet nichts. Dieselbe Änderung in einer fertigen Anwendung kostet immer. Deshalb ist bei uns alles frei, was am Modell geändert wird. Was danach kommt, bekommt vorher einen benannten Preis statt einer Rechnung nach Aufwand.
Die Abnahme des Modells ist damit ein Termin mit Folgen. Ihr habt dafür zehn Werktage ab dem Tag, an dem es euch vorliegt. Danach gilt es als abgenommen, und der Umfang steht.
Genau darum steht das Modell am Anfang und nicht am Ende. Ein Missverständnis kostet an dieser Stelle eine Korrektur. Dasselbe Missverständnis nach acht Wochen Bauzeit kostet einen Umbau, und ihr bezahlt Arbeit, die schon fertig war.
Was ihr in der Hand habt, wenn niemand weiterbaut
Das Modell gehört euch, sobald es fertig ist. Auch dann, wenn ihr danach nicht weiterbaut oder jemand anderen bauen lasst. Ihr habt es bezahlt, und es ist das Einzige an einem Softwareprojekt, das ohne die Software weiterlebt.
- Das Fachmodell eures Geschäfts, schriftlich
- Ein Leistungsumfang mit dem, was ausdrücklich nicht dazugehört
- Der Quellcode, der daraus entsteht, in eurem eigenen Repository
Wer danach weiterbaut, muss nicht raten, wie euer Geschäft funktioniert. Das ist der Unterschied zu einer Sammlung erledigter Tickets. Die erzählt, was einmal gemacht wurde. Sie erzählt nicht, was gelten soll.
Marke und Produkt, die zusammen wachsen.
In 30 Minuten klären wir, was bei euch ansteht und welches Programm dazu passt.
Häufige Fragen zu diesem Thema.
Offene Fragen?
30 Minuten mit Niklas und Rolf, kostenlos. Danach wisst ihr, wie es weitergeht.
Man beschreibt zuerst das Geschäft und baut die Software danach daraus. Dazu gehören die Dinge, die darin vorkommen, die Regeln zwischen ihnen und die Zustände, die erlaubt sind. Bei uns ist das der erste Schritt in Headgent® Build, und er steckt im Festpreis.
Ein Fachmodell besteht aus Sätzen wie diesen. Ein Auftrag braucht eine Freigabe, bevor er abgerechnet wird. Eine Rechnungsnummer gibt es nur einmal. Wer im Vertrieb arbeitet, sieht die Zahlen seines Bereichs und nicht die der anderen. Jeder dieser Sätze ist eine Regel, an die sich das Programm danach hält.
Ja. Tickets sind gut darin, Arbeit zu verteilen und Fortschritt sichtbar zu machen. Sie sind nur kein Ort für Regeln, die dauerhaft gelten. Beides nebeneinander funktioniert, solange die Regel im Modell steht und das Ticket nur sagt, was als Nächstes gebaut wird.
Dann ändert sich zuerst das Modell und danach die Anwendung. Eine neue Regel landet an einer Stelle, und ihr seht vorher, was sie sonst noch berührt. Kleine Erweiterungen laufen später über Headgent® Partner, ein neues Fachmodell ist ein eigenes Projekt.
Passt zu dem, was ihr gerade gelesen habt.
Build what's next.
Erzählt uns, was ihr vorhabt, und wir sagen euch, wie wir gemeinsam dorthin kommen.
Projekt starten