Die Architektur hinter diesem Blog beginnt nicht mit Technik. Sie beginnt mit einer Haltung. Ich wollte ein System bauen, das nicht größer wirkt, als es ist, aber auch nicht kleiner denkt, als es muss. Ein Blog ist auf den ersten Blick einfach. Artikel schreiben, Artikel anzeigen, vielleicht mehrere Sprachen, eine Übersicht, Detailseiten, Suchmaschinenfreundlichkeit, fertig. Aber genau darin liegt der Reiz. Denn an einem einfachen System sieht man sehr schnell, ob Architektur wirklich klar ist oder ob sie nur durch Komplexität beeindruckt. Für mich ist Architektur zuerst Ordnung. Nicht Ordnung im bürokratischen Sinn, sondern eine innere Ordnung der Verantwortlichkeiten. Jede Schicht soll wissen, was sie tut. Das Domain-Modell soll nicht vom Framework abhängig sein. Die API soll nicht einfach Daten ausspucken, sondern ausdrücken, welche Möglichkeiten ein Client hat. Das Rendering soll nicht zufällig entstehen, sondern bewusst entscheiden, was für Menschen, Suchmaschinen und Maschinen lesbar sein soll. Der Build soll nicht nebenbei existieren, sondern das Projekt zuverlässig zusammenhalten. Deshalb ist der Blog bewusst aus wenigen, aber tragenden Teilen gebaut. Scala 3 gibt mir die Sprache, um präzise zu modellieren. Java EE 11 gibt mir eine stabile serverseitige Grundlage. SBT hält das Projekt zusammen und macht den Build explizit. Serverseitiges Rendering sorgt dafür, dass der Blog nicht erst durch JavaScript wirklich existiert, sondern schon als HTML lesbar ist. Das ist für mich wichtig, weil ein Blog nicht zuerst eine App ist. Ein Blog ist zuerst ein Dokument im Netz. Er soll gefunden werden können. Er soll verstanden werden können. Er soll auch dann eine klare Form haben, wenn noch kein Client-Code ausgeführt wurde. Die wichtigste Entscheidung ist aber: Domain zuerst. Der Artikel ist nicht einfach eine Datenbankzeile und auch nicht nur ein JSON-Objekt. Er ist ein fachliches Objekt. Er hat Inhalt, Sprache, Veröffentlichung, Sichtbarkeit, vielleicht einen Zustand, vielleicht eine Übersetzung, vielleicht eine Beziehung zu anderen Texten. Wenn man diese Dinge zu früh nur technisch behandelt, verliert man die Architektur. Dann wird aus Fachlichkeit bloß Infrastruktur. Genau das wollte ich vermeiden. Die API ist deshalb nicht als bloßer Datentunnel gedacht. Sie ist eine Schnittstelle zwischen Fachmodell und Oberfläche. Sie soll dem Client nicht nur sagen, welche Daten existieren, sondern auch, was mit ihnen möglich ist. In größeren Systemen wird das entscheidend. Ein Client sollte nicht raten müssen, welche Aktionen erlaubt sind, welche Felder sichtbar sind oder welche Beziehung ein Objekt zu anderen Objekten hat. Das System selbst sollte diese Struktur ausdrücken können. Für einen Blog klingt das vielleicht übertrieben. Aber gerade ein kleines System ist ein guter Ort, um diese Klarheit sauber zu zeigen. Auch SSR gehört für mich zu dieser Architektur. Ich wollte nicht, dass der Blog nur als leere Hülle ausgeliefert wird und erst im Browser zu einem Inhalt wird. Das Netz versteht HTML. Suchmaschinen verstehen HTML. KI-Systeme lesen HTML. Menschen lesen am Ende natürlich die gerenderte Seite, aber die Grundlage sollte schon vorher sinnvoll sein. SSR ist für mich deshalb kein nostalgischer Rückschritt, sondern eine Rückkehr zur Ehrlichkeit des Webs. Was ein Dokument ist, sollte auch als Dokument ausgeliefert werden. Dabei geht es nicht darum, moderne Frontend-Technik abzulehnen. Es geht darum, sie richtig einzuordnen. JavaScript kann Interaktivität geben. CSS kann Atmosphäre geben. Komponenten können Struktur geben. Aber der Inhalt darf nicht davon abhängig werden, dass erst eine ganze Maschine im Browser hochfährt. Ein Blogartikel sollte im Kern schon da sein. Ruhig. Lesbar. Greifbar. Die Architektur dieses Blogs ist also bewusst unspektakulär. Sie will nicht durch möglichst viele Frameworks glänzen. Sie will zeigen, dass Klarheit stärker ist als Effekt. Es gibt keine Magie, wo einfache Struktur reicht. Es gibt keine Workarounds, wo ein Problem eigentlich sauber verstanden werden muss. Und es gibt keine technische Abkürzung, die später die Form beschädigt. Mich interessiert an diesem Blog besonders, dass er klein genug ist, um verstanden zu werden, aber groß genug, um echte Architekturfragen sichtbar zu machen. Wie trennt man Domain und Infrastruktur? Wie verhindert man, dass das Framework die Fachlichkeit verschluckt? Wie baut man eine API, die nicht dumm ist? Wie rendert man Inhalte so, dass sie im Web wirklich existieren? Wie hält man ein Projekt so schlicht, dass es erweiterbar bleibt? Das ist für mich die eigentliche Architektur hinter diesem Blog: ein ruhiges System, das zeigt, wie ich denke. Nicht perfekt, nicht endgültig, aber bewusst gebaut. Ein Blog als kleines Fachsystem. Ein Ort, an dem Text, Domain, API, Rendering und Build nicht zufällig nebeneinanderliegen, sondern eine gemeinsame Form bekommen. Gute Architektur macht ein System nicht schwerer. Sie macht es tragfähiger. Und genau das soll dieser Blog zeigen.