Endlich eine gute Architekturdokumentation

State Is the Root of All Evil

Hi,

Was unterscheidet eine Anwendung von einer (mathematischen) Funktion?

Eine Funktion nimmt einen Input x und transformiert ihn zu einem Output. Wenn gilt f(x) = 2 * x, dann ist das Ergebnis dieser Funktion bei der Eingabe von jedem x immer gleich.

Es gibt keine Seiteneffekte. Wir nennen dieses Verhalten stateless.

Aber was hat das mit der Frage vom Anfang zutun? Eine Anwendung geht darüber hinaus. (Fast) jede Anwendung muss mit State arbeiten. Sobald wir I/O Operations in unserem System haben, haben wir inhärent State. Und häufig kann ein methodenaufruf, mit dem gleichen Input, zu unterschiedlichen Zeiten, unterschiedliche Resultate liefern. Und das ist auch nicht vermeidbar und liegt in der Natur der Aufgabe, die wir lösen wollen.

Marcus Held

Sliced Onion Architecture

Hi,

Vor einer Woche hat Oliver Drotbohm eine erweiterte Idee der Onion Architecture publiziert: The Sliced Onion Architecture .

Hexagonal Architecture und deren Erweiterung die Onion Architecture sind den meisten Softwareentwicklern bekannt. Die Idee (vereinfacht): Man decoupled seinen Businesscode mithilfe von Adaptern von Infrastrukturcode.

Damit ist es weniger wahrscheinlich den “Big Ball of Mud” zu erschaffen.

Was sehe ich in der Praxis?

Die meisten Entwickler haben verstanden, dass es eine gute Idee den Businesscode nicht mit Infrastrukturcode zu vermischen.

Marcus Held

Double-Entry Bookkeeping

Hi,

Ein Fehler in der Buchhaltung kann teuer sein. Gerade in großen Unternehmen, in denen es sehr viele Transaktionen gibt, ist es leicht eine zu übersehen.

Und wenn das passiert, dann merke ich es noch nicht einmal. Vielleicht steht das Unternehmen viel besser da, als es die Bücher hergeben? Oder vielleicht ist es eigentlich unprofitabel?

Die Kaufleute haben im 13 Jahrhundert das Problem erkannt. Es musste ein System gefunden werden, dass Fehler unwahrscheinlicher macht. Es wurde die doppelte Buchhaltung erfunden.

Marcus Held

Microservices are a Big Ball of Mud

Over the past years I attended hundreds of interviews. Many candidates proudly told tales on how they develop their projects with a microservice architecture. Often (I don’t want to say “always”, but from my memory I think it actually is “always”) it does not require many questions to see that they used a rocket launcher to kill a mouse. Microservices are hard. Everyone who experienced the pain of operating such an architecture can relate to it. The complexity kills you at one point or the other. You already had to do multiple refactorings of your architecture - because your domains didn’t work out. I wonder - why is this architecture so appealing to developers? And then I remember why I found them appealing 10 years ago.

Marcus Held