Hi,

Ein alter Entwicklerwitz:

There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. – Leon Bambrick

Oder als Variante:

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery – Mathias Verraes

Und es gibt etliche weitere:

There are so many variations on the “there are only two hard problems in computer programming…” joke that I’m starting to suspect that programming isn’t actually very easy. – Nat Pryce

(Credit to Martin Fowler für diese Liste)

Ich möchte heute über ein Thema schreiben, das nicht nur schwierig ist - sondern auch verdammt teuer, wenn man es falsch macht.

Der Modulschnitt

Die Frage ist so alt wie die Informatik selbst. Von Anfang an wurde verstanden, dass es sinnvoll ist, zu abstrahieren und in sich geschlossene Funktionen zu gruppieren. Und der Hype um DDD und Microservices hat das Thema weiter befeuert. Gerade, wenn man die Module in eigene Services auslagert, wird die Entscheidung besonders teuer. Ein Garant für Accidental Complexity .

Es stellt sich also die Frage: Wie schneide ich meine Module?

Es gibt ganze Bücher über diese Frage. In diesem Newsletter die Frage beantworten zu wollen, wäre anmaßend.

Ich habe aber eine schöne Visualisierung von Kent Beck gesehen, die mir hilft, die Frage zu reflektieren.

Stell dir vor, der rote Bereich entspricht einem Feature/Komponente/Datenstruktur. Es passt für alles.

Ich kann die Visualisierung auf allen Ebenen verwenden:

• Ist mein Service richtig geschnitten?
• Ist meine Klasse richtig geschnitten?
• Ist meine Funktion richtig geschnitten?
• Ist meine Entität richtig geschnitten?

Interessanterweise sehe ich die meisten Fehler heute in der Mitte. Die meisten Strukturen sind zu klein .

Der Hype um Microservices lässt viele zu kleine Services in der Architektur schneiden.

Zu strenge Normalisierung in der Datenbank verteilt die Daten auf zu viele Tabellen.

Zu starke Auslegung des Single-Responsibility-Prinzips lässt Entwickler zu viele Klassen für eine Funktion schreiben.

Seltener sehe ich, dass Dinge zu groß sind. Es gibt sie aber auch zur Genüge. Der berüchtigte Spaghetti-Monolith. Die Kunst ist es, es genau richtig zu machen. Das schaffe ich aber selten im ersten Anlauf. Das muss auch nicht dein Anspruch sein. Tendiere aber nicht zum einen oder anderen Extrem.

Es ist wie mit allem im Leben: Tendiere zur gesunden Mitte.

Rule the Backend,

~ Marcus