Archiv der Kategorie: German

Microservices mögen kein Denken in klassischen Entitäten

Einen ganz besonderen AHA Moment hatte ich kürzlich in einem Workshop bei Udi Dahan, CEO von Particular. In seinem Beispiel ging es um die klassische Entität eines Kunden.

Microservices zu realisieren bedeutet Fachlichkeiten sauber schneiden und in eigenständige Silos (oder Säulen) packen zu müssen. Jedes Silo muss dabei die Hohheit über die eigenen Daten besitzen, auf denen es die zugehörigen Geschäftsprozesse abbildet. Soweit so gut. Doch wie lässt sich dies im Falle eines Kunden bewerkstelligen, der klassischerweise wie im Screenshot zu sehen modelliert ist? Unterschiedliche Eigenschaften werden von unterschiedlichen Microservices benötigt bzw. verändert.

Wird die gleiche Entität in allen Silos verwendet, muss es eine entsprechende Synchronisierung zw. den Microservices geben. Das hat erhelbiche Auswirkungen auf Skalierbarkeit und Performance. In einer Applikation mit häufig parallelen Änderungen an einer Entität wird das Fehlschlagen von Geschäftsprozessen zunehmen – oder im schlimmsten Fall zu Inkonsistenzen führen.

Klassische Kundeentität

Klassische Kundeentität

 

Udi schlägt die folgende Modellierung vor:

Neue Modellierung eines Kunden

Der Kunde wird durch unabhängige Entitäten modelliert

Zur Identifikation, welche Daten zusammengehören, schlägt Udi einen Interessanten Ansatz vor:

Fragt die Fachabteilung, ob das Ändern einer Eigenschaft Auswirkung auf eine andere Eigenschaft hat. 

Würde das Ändern des Nachnamens einen Einfluss auf die Preiskalkulation haben? Oder auf die Art der Marketings?

Nun gilt es noch das Problem der Aggregation zu lösen, sprich wenn ich in meiner Anzeige unterschiedliche Daten unterschiedlicher Microserivces anzeigen möchte. Klassischerweise würde es jetzt eine Tabelle geben, die die Spalten

 

ID_Kunde ID_Kundenstamm ID_Bestandskundenmarketing ID_Preiskalkulation

 

besitzt. Das führt aber zu 2 Problemen:

  1. Die Tabelle muss immer erweitert werden, wenn ein neuer Microservices hinzugefügt wird.
  2. Sofern ein Microservices die gleiche Funktionalität in Form unterschiedlicher Daten abdeckt, müssten pro Microservices mehrere Spalten hinzugefügt und NULL Werte zugelassen werden.

Ein Beispiel für Punkt 2 wäre ein Microservices, der das Thema Bezahlmethoden abdeckt. Anfangs gab es beispielsweise nur Kreditkarte und Kontoeinzug. Dann folgte Paypal. Und kurze Zeit später dann Bitcoin. Der Microservices hätte hierzu mehrere Tabellen, wo er die individuelle Daten für die jeweilige Bezahlmethode halten würde. In oben gezeigter Aggregationstabelle müsste aber für jede Bezahlmethode, die der Kunde nutzt, eine Spalte gefüllt werden. Wenn er sie nicht benutzt, würde NULL geschrieben werden. Man merkt schon: Das stinkt.

Ein anderer Ansatz ist da deutlich besser geeignet. Welcher das ist und wie man diesen technischen realisieren kann, könnt ihr im GitHub Repository von Particular nachschauen.

 

Advertisements

Quellen zu Defensives Design und Separation of Concerns sind jetzt online

Den Quellcode zu meinen Vorträgen auf den Karlsruher Entwicklertagen und der DWX sind jetzt online:

  • Zu Super Mario Kata mit Fokus auf Defensivem Design geht es hier.
  • Zur Prüfsummen Kata mit fokus auf Separation of Concerns gelangt ihr hier.

Auf beiden Seiten findet ihr auch die Links zu den PowerPoint Folien. Im Juli 2018 werde ich den Code der Prüfsummen Kata noch in Form von Iterationen veröffentlichen und beide Talks als YouTube Video freigeben.

IMG_20180627_145405

Defensives Design Talk auf der DWX

Ihr wollt Teile davon in euren Vorträgen verwenden, ihr wollt ein Training zu dem Thema oder ich soll dazu in euerer Community einen Vortrag halten, dann kontaktiert mich über die auf GitHub genannten Kanäle.

Kausale Ketten: Gründe für das Scheitern von Softwareprojekten

Auf dieser Github Page habe ich begonnen die Problemen in Softwareprojekten, die uns täglich begegnen, genauer zu analysieren, um diese vermeiden bzw. beheben zu können.

In Gesprächen mit Teilnehmern meiner Workshops werden mir regelmäßig Symptome geschildert, von denen ich der Meinung bin, dass die Ursache wie so oft tiefer liegt.

Tituliert habe ich das als kausale Ketten und orientiere mich dabei an folgendem Schema:

  • Was ist das wahrgenommene Problem, also das Symptom
  • Wie kam es dazu, also die Verlaufsbetrachtung
  • Warum kam es dazu, was ist die Ursache

Zudem suche ich nach nachvollziehbaren Beispielen, um die Theorie zu untermauern.

Ich verstehe die Seite als Anreiz zum Nachdenken. Alle „Thesen“ sollen als Einstieg in eine lebendige Diskussion dienen.

Gebt mir gerne Feedback in Form von Pull Requests.

Termin nossued 2019

In diesem Jahr fand der #nossued noch vor Beginn der Sommerferien in den meisten Bundesländern statt. Das Feedback der letzten Jahren ging dahin, dass der ein oder andere aufgrund der Schulferien nicht kommen konnte.

Neben der Berücksichtung von zeitlich verschobener Ferien in den einzelnen Bundesländern gilt es natürlich noch auf etablierte Events wie die dotnet Cologne Rücksicht zu nehmen.

Der ein oder andere hadert mit Juni/Juli auch wegen den alle 2 Jahre stattfindenden Fußballturnieren oder weil die warme Sommerzeit lieber für Freizeitaktivitäten genutzt wird. Andere wiederum schätzen genau die strahlende Sonne und die Möglichkeit die Dachterrasse nutzen zu können.

Daher würden wir von der Organisation gerne wissen, wie ihr zu den möglichen Terminen 2019 steht. Denkbar wären auch frühere Termine wie die Zeiträume vom 08. März bis 04. April und 27. April bis 31. Mai. Wie steht die Community dazu?

Eure Rückmeldungen würden uns freuen, z.B. in Form von Nennung von guten Zeiträumen oder weniger geeigneten Monaten.

Beispiele für Zielvereinbarungen

Allgemeines

Dieser Beitrag soll als kleine Hilfestellung für all diejenigen dienen, die sich mit der Findung von guten Zielen schwertun. Wer wie wir darauf hinarbeitet, dass die Mitarbeiter sich aus der Unternehmensstrategie die individuellen Ziele selbst ableiten und der Vorgesetzte nur noch unterstützende Funktion (z.B. Bereitstellen von Resourcen) ausüben muss, der wird zuerst viel kommunizieren und beraten müssen.

Während die eine Seite erfolgreicher Zielvereinbarungen die Verlagerung der Zieldefinition auf den Mitarbeiter selbst ist, ist die andere das Sichtbarmachen der operativen und strategischen Unternehmensziele. Damit einher geht natürlich das kontinuierliche Gespräch über die gemeinsame Unternehmenskultur. Beispielsweise wird es schwierig über monetäre Ergebnisziele zu sprechen, wenn die Kennzahlen nicht transparent zur Verfügung gestellt und erklärt werden. Nicht jeder Chef ist davon begeistert, wenn die Angestellten die genauen Margen von Aufträgen kennen.

  • Der Kern guter Ziele sind die S.M.A.R.T. Kriterien, auf die an dieser Stelle nicht weiter eingegangen werden soll.
  • Die Ziele drüfen sich nicht gegenseitig beeinträchtigen. Stattdessen sollen sie sich vielmehr gegenseitig beflügeln.
  • Die Erreichung des Ziels soll immer einen direkten oder indirekten Benefit für das Unternehmen haben (Stichwort Return on Invest).

 

Auf den Punkt gebracht: Die Mitarbeiter müssen um die Unternehmsziele wissen und diese mittragen. Ein gemeinsames Verständnis der Modalitäten und eine dazu passende Informationstransparenz sind ebenso elementar wie das Mitwirkenwollen des Einzelnen.

 

Beispiele für individuelle Ziele

  • Community Auftritte
    • Bis 31.12.18 hält der Mitarbeiter in den User Groups Berlin, Dresden, Leipzig, Chemnitz, Karlsruhe und Luzern Vorträge
  • Fachartikel
    • Bis 31.12.18 publiziert der Mitarbeiter 3 Fachartikel in Fachzeitschriften (z.B. in der dotnetpro)
  • Öffentliche Auftritte auf Konferenzen
    • Bis 31.12.18 hält der Mitarbeiter auf mind. 3 unterschiedlichen, kommerziellen Konferenzen Talks oder Trainings (z.B. DWX, Karlsruher Entwicklertage etc.)
  • Kommerzielle Workshops
    • Bis 31.12.18 generiert der Mitarbeiter durch Workshops einen Gesamtumsatz von mind. 20.000€
  • Fakturierung
    • Bis 31.12.18 fakturiert der Mitarbeiter durch Consulting mind. 800 Stunden.
  • Zertifizierung

Ideen für das Format des NOSSUED 2018 gesucht

Vom 16-17. Juni 2018 findet wieder der NOSSUED in Karlsruhe statt. Der Termin wurde vorgezogen, um den unterschiedlichen Sommerferien der einzelnen Bundesländer Rechnung zu tragen.

Wie jedes Jahr soll die Konferenz als Open Space ausgerichtet werden. Darüber hinaus suchen wir als Orga nach Ideen, um das Format zu erweitern und neue Anreize einfließen zu lassen.

Beispielsweise wäre ein Mix aus Charity Development, Hackathon und Open Space möglich. Dabei würde im Vorhhinein, z.B. über einen Austausch auf Facebook oder am Vorabend des NOSSUED, ein Projekt ausgewählt werden, welches Schulen oder Vereine einsetzen können. Eine webbasierte Mitgliederverwaltung samt deren Mitgliedsbeiträge für Sportvereine wäre so etwas. Im Anschluss würden wir uns darüber austauschen welche Technologien dazu eingesetzt und wir die Architektur aufgebaut werden sollen. Die Sessions des Open Spaces würde dann auf diese Themen ausgerichtet werden. Parallel findet in Gruppen ein Hackathon statt, bei dem das Produkt entwivckelt wird. Ergeben sich dabei Fragen, Diskussionen oder Schwierigkeiten, dann kann daraus eine neue Open Space Session generiert und spontan abgehalten werden.

Was sagt ihr zu diesem Ansatz? Habt ihr andere Ideen? Oder wollt ihr vielleicht am bisherigen Format gar nichts ändern? Schreibt mir in die Kommentare.

Workshop: Conquer your Codebase – Bewährter Clean Code aus der Praxis (Materialien)

Einen herzlichen Dank an alle Teilnehmer des Workshops am vergangenen Freitag beim Developer Open Space 2017. Trotz des völlig unterschiedlichen Backgrounds – von Ruby, über PHP, zu Java oder gar nicht objektorientierte Sprachen wie JavaScript – war ebenso alles vertreten wie vom Azubi bis hin zum Entwickler mit 20-jähriger Berufserfahrung.

IMG_20171013_132904

Einer von vielen mutigen Freiwilligen

Den Code zur Super Mario Kata gibt es hier. Beachtet die neuen Anforderungen (9-12), die ich auf dem Heimweg im Zug noch hinzugefügt habe. Damit einhergehend habe ich noch ein Refactoring des Konzepts ‚Leben‘ durchgeführt, sodass keine Actions bzw. Funcs mehr an die Methoden übergeben werden müssen. Gleichfalls fällt das Branching-Statement raus und es ergibt sich eine nahezu völlig flexible Möglichkeit zur Erstellung von Spielmodi. Die Tests sind nun ebenfalls alle umgesetzt, was wir gegen Ende hin aufgrund von Zeitmangel ausgelassen haben. Eine Testmethode hat in der Regel eine Zeile und wie schon im Workshop erwähnt: Was gut zu testen ist, ist in der Regel auch eine saubere Lösung.

IMG_20171013_132938

20 Teilnehmer mit unterschiedlichen Backgrounds

Derjenige, der noch eine Lösung mit dem Command-Pattern umsetzt und dadurch das Anpassen bestehender Klassen völlständig vermeidet, erhält von mir einen Gutschein für unsere Trainings. Damit kann er kostenlos an jedem beliebigen 3-tägigen Workshop in unseren Karlsruher Büros teilnehmen (Fahrt- und Übernachtungskosten sind ausgeschlossen).

Alle, die über den Workshop bloggen oder twittern, erhalten darüber hinaus noch einen 30% Rabattcode. Einfach Link schicken, dann kriegt er diesen per Mail.

tweet-workshop

Ein Teilnehmer versucht sich in einer Lösung mit Java statt C#

Weiterführende Links

  • Das erwähnte Video zu Enumeration mit Verhalten könnt ihr hier anschauen.
  • Danke an Tim für den Link zum Case Converter für Visual Studio.
  • Außerdem lege ich euch die Reactive Extensions ans Herz, die es für unterschiedliche, gängige Programmiersprachen gibt.
  • Git Snippet
  • Wer noch ein wenig üben möchte, kann dies mit der erweiterten FizzBuzz Kata tun.
  • Blog Post über die Migration von NHibernate zu EntityFramework in 3 Tagen.

 

Demnächst geht ein Video mit dem theoretischen Teil (Why-How-What) online, in dem ich nochmal die Zusammenhänge zw. „schlechtem Code“ und den Gründen dafür erläutere. Wer automatisch informiert werden will, wenn es veröffentlich wird, abonniert einfach meinen Blog oder schickt mir eine Nachricht.

 

 

%d Bloggern gefällt das: