© Liashko/Shutterstock.com
Entwickler Magazin
Bausteine für erfolgreiches Domain-driven Design

DDD-Patterns

Anstatt im ersten Schritt auszuwählen, welches MVC-Framework man einsetzen möchte, sollte man sich viel stärker auf die Fachlichkeit konzentrieren. Dieser Artikel zeigt, welche Entwurfsmuster Sie kennen müssen, um bei der Entwicklung die Fachlichkeit anstelle technischer Aspekte in den Mittelpunkt zu stellen.

Stefan Priebsch


Im vorhergehenden Artikel „Ketchup oder Mayo?“ haben wir eine Pommesbude eröffnet – natürlich nur als Gedankenspiel. Im Zuge der Eröffnung gab es zahlreiche Entscheidungen zu treffen: Wir haben unter anderem gesehen, dass es sich nicht empfiehlt, zu früh auf technische Details zu fokussieren und dass es essenziell ist, mit dem Kunden in dessen Fachsprache zu sprechen, anstattt ihn mit technischen Begriffen zu verwirren.

Die Idee, die Fachlichkeit in den Mittelpunkt der Softwareentwicklung zu rücken (Domain-driven Design), zahlt sich besonders bei der Entwicklung von komplexen Systemen aus. Wobei wir im vorherigen Artikel ja bereits gesehen hatten, dass selbst ein scheinbar einfaches Business wie eine Pommesbude eine erstaunliche Komplexität innehat, wenn man nur einmal genauer hinschaut. In diesem Artikel sehen wir uns die wichtigsten Entwurfsmuster an, die beim Domain-driven Design zum Einsatz kommen.

Obwohl es wichtig und lehrreich ist, die vorgestellten Muster zu kennen, zu verstehen und deren Einsatz einzuüben, fokussieren die Entwurfsmuster auf die Implementierung und nicht auf den besonders wichtigen strategischen Teil des Domain-driven Design (DDD). DDD ist mehr als nur eine Sammlung von Entwurfsmustern. DDD ist eine Entwicklungsphilosophie, und es braucht durchaus seine Zeit, bis man sich von den bisherigen Sicht- und Denkweisen löst und sich für diese neue Sichtweise öffnen kann.

Entity

Wir beginnen mit dem vermeintlich wichtigsten Muster, der Entität (Entity). Hierbei handelt es sich um ein (persistentes) Objekt mit einer Identität. Typische Beispiele hierfür sind Personen oder Kunden, die eine eindeutige Identität haben, die nicht von ihren Attributen abhängt. Herr Müller ist nicht unbedingt Herr Müller, auch wenn der Vorname gleich ist. Hinzu kommt, dass sich Attribute über die Zeit ändern können: Menschen ändern etwa ihren Namen, wenn sie heiraten. Sie können sogar ihr Geschlecht ändern. Es soll auch schon vorgekommen sein, dass sich der (zunächst angenommene) Geburtstag etwa von Flüchtlingen als falsch erweist, wenn plötzlich ihre Geburtsurkunde auftaucht.

Es empfiehlt sich, für jede Entität ein eigenes ID-Objekt zu erstellen. Im nachfolgenden Beispiel basiert diese PersonId auf einer UUID und wir gehen einfach davon aus, dass ein entsprechendes Objekt existiert. Interessant ist, dass weder die Klasse Person noch irgendwelcher anderer Code von UUID abhängen – UUID ist ein Implementierungsdetail von PersonId. Wir könnten in einer alternativen Im...

Entwickler Magazin
Bausteine für erfolgreiches Domain-driven Design

DDD-Patterns

Anstatt im ersten Schritt auszuwählen, welches MVC-Framework man einsetzen möchte, sollte man sich viel stärker auf die Fachlichkeit konzentrieren. Dieser Artikel zeigt, welche Entwurfsmuster Sie kennen müssen, um bei der Entwicklung die Fachlichkeit anstelle technischer Aspekte in den Mittelpunkt zu stellen.

Stefan Priebsch


Im vorhergehenden Artikel „Ketchup oder Mayo?“ haben wir eine Pommesbude eröffnet – natürlich nur als Gedankenspiel. Im Zuge der Eröffnung gab es zahlreiche Entscheidungen zu treffen: Wir haben unter anderem gesehen, dass es sich nicht empfiehlt, zu früh auf technische Details zu fokussieren und dass es essenziell ist, mit dem Kunden in dessen Fachsprache zu sprechen, anstattt ihn mit technischen Begriffen zu verwirren.

Die Idee, die Fachlichkeit in den Mittelpunkt der Softwareentwicklung zu rücken (Domain-driven Design), zahlt sich besonders bei der Entwicklung von komplexen Systemen aus. Wobei wir im vorherigen Artikel ja bereits gesehen hatten, dass selbst ein scheinbar einfaches Business wie eine Pommesbude eine erstaunliche Komplexität innehat, wenn man nur einmal genauer hinschaut. In diesem Artikel sehen wir uns die wichtigsten Entwurfsmuster an, die beim Domain-driven Design zum Einsatz kommen.

Obwohl es wichtig und lehrreich ist, die vorgestellten Muster zu kennen, zu verstehen und deren Einsatz einzuüben, fokussieren die Entwurfsmuster auf die Implementierung und nicht auf den besonders wichtigen strategischen Teil des Domain-driven Design (DDD). DDD ist mehr als nur eine Sammlung von Entwurfsmustern. DDD ist eine Entwicklungsphilosophie, und es braucht durchaus seine Zeit, bis man sich von den bisherigen Sicht- und Denkweisen löst und sich für diese neue Sichtweise öffnen kann.

Entity

Wir beginnen mit dem vermeintlich wichtigsten Muster, der Entität (Entity). Hierbei handelt es sich um ein (persistentes) Objekt mit einer Identität. Typische Beispiele hierfür sind Personen oder Kunden, die eine eindeutige Identität haben, die nicht von ihren Attributen abhängt. Herr Müller ist nicht unbedingt Herr Müller, auch wenn der Vorname gleich ist. Hinzu kommt, dass sich Attribute über die Zeit ändern können: Menschen ändern etwa ihren Namen, wenn sie heiraten. Sie können sogar ihr Geschlecht ändern. Es soll auch schon vorgekommen sein, dass sich der (zunächst angenommene) Geburtstag etwa von Flüchtlingen als falsch erweist, wenn plötzlich ihre Geburtsurkunde auftaucht.

Es empfiehlt sich, für jede Entität ein eigenes ID-Objekt zu erstellen. Im nachfolgenden Beispiel basiert diese PersonId auf einer UUID und wir gehen einfach davon aus, dass ein entsprechendes Objekt existiert. Interessant ist, dass weder die Klasse Person noch irgendwelcher anderer Code von UUID abhängen – UUID ist ein Implementierungsdetail von PersonId. Wir könnten in einer alternativen Im...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang