Go meetup #18

**Gehostet von Pure Storage**

Bitte beachten Sie, dass im Pure Storage-Büro alle Teilnehmer des Treffens eine allgemeine Geheimhaltungsvereinbarung unterzeichnen müssen, die für alle Bürobesucher gilt, um am Treffen teilnehmen zu können.
Der Einlass ist ab 17:30 Uhr, die Vorträge beginnen um 18:00 Uhr und wir haben 3 Vorträge.

**1\. Vilibald Wanča \(Pure Storage\)\, Einführung in die zellenbasierte Architektur**

**2\. Miłosz Smółka\, Killing the Legacy und andere CQRS-Geschichten**
Kennen Sie das Gefühl, wenn Ihr Projekt stecken bleibt und Sie nicht weiterkommen? Sie sehen ein paar Auswege, aber alle scheinen gleich schlecht zu sein. Sie beginnen sich zu fragen, ob das Projekt zum Scheitern verurteilt ist oder ob Ihnen einfach einige Spezialkenntnisse fehlen. Ich habe das am meisten gespürt, als ich versucht habe, alte Systeme zu verlassen, aber es ist bei vielen Projekten üblich.
Mit der Zeit habe ich gelernt, dass eine Änderung Ihres mentalen Modells eine Lösung offenbaren kann, die Sie vorher nicht gesehen haben. Als ich auf einige meiner Projekte zurückblickte, wurde mir klar, dass eines der Muster, das mir geholfen hat, anders zu denken, CQRS war. Es spielt keine Rolle, ob Sie CQRS schon einmal verwendet haben, da ich nicht vorhabe, Sie mit abstrakten Definitionen zu langweilen. Über die Theorie von CQRS ist viel gesagt worden. Stattdessen möchte ich zeigen, wie ich es in der Praxis eingesetzt habe. Ich werde drei echte Geschichten aus verschiedenen Unternehmen und Projekten erzählen, bei denen es mir gelungen ist, voranzukommen und CQRS besser zu verstehen. Eine davon war die größte Herausforderung: die Zerstörung der alten Codebasis.

**Bio:** Miłosz Smółka schreibt über Go, moderne Unternehmenssoftware und verwandte Themen bei [https:// threedots.tech](https:// threedots.tech/). Es macht ihm Spaß, das zu teilen, was er bei der Arbeit bei Startups und der Entwicklung von Produkten in verschiedenen Bereichen gelernt hat.

**3\. Robert Laszczak\, Domain-Driven Design in Go neu denken: Von Mythen zu reduzierter Projektkomplexität**
Die Aufteilung von Problemen in kleinere Probleme kann eine gute Strategie zur Lösung komplexer Probleme sein. Aber manchmal passiert das Gegenteil, anstatt die Projektentwicklung zu beschleunigen. Letztendlich erfordert die Entwicklung der einfachsten Funktion die heldenhafte Arbeit von 10 Teams an einem Dutzend Microservices über ein halbes Jahr. Kommt Ihnen das bekannt vor?
„Teile und herrsche“ ist nicht die einzige Strategie, die wir in komplexen Projekten umsetzen können. Einer der etabliertesten Ansätze, der die Implementierung von Funktionalitäten mit komplexer Domänenlogik vereinfachen kann, ist Domain-Driven Design (DDD).
Ich fand DDD in mehreren Projekten mit komplexen Domänen, an denen ich arbeiten konnte, sehr nützlich. Andererseits weiß ich, dass die Leute an viele Mythen über die in Go verwendete DDD glauben. Die meisten davon stammen aus der Verwendung von DDD in Projekten, die keinen so ausgefeilten Ansatz erfordern, oder aus Projekten, die von Leuten durchgeführt wurden, die die Prinzipien von DDD nicht verstanden haben.
In diesem Vortrag werde ich DDD entmystifizieren und Ihnen ein Beispiel aus der Praxis geben, wie die Stärkung von DDD dazu beigetragen hat, sie zu vereinfachen und die Entwicklungsgeschwindigkeit zu erhöhen.
Wenn Sie derzeit nicht an einem Projekt mit komplexer Domänenlogik arbeiten, kann diese Präsentation dennoch hilfreich für Sie sein, wenn Sie in Zukunft an anspruchsvolleren Projekten arbeiten möchten. Außerdem gebe ich Ihnen einige Hinweise, mit welchen Teilen von DDD Sie beginnen sollten und welche Techniken mit DDD gut funktionieren.

**Bio:** Ich blogge bei threedots.tech. Autor von „Go With The Domain“ und [Watermill.io](https://watermill.io/).
Meine Programmierkarriere erstreckt sich über 16 Jahre, in denen ich in verschiedenen Bereichen navigiert habe, darunter Infrastruktur, globale Finanzplattformen und Sicherheit. Vor ein paar Jahren habe ich endlich eine Sprache gefunden, die ich liebe: Go.