<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture :: Tag :: onlythoughts</title><link>https://private.onlythoughts.io/tags/architecture/index.html</link><description/><generator>Hugo</generator><language>de-ch</language><lastBuildDate>Fri, 10 Jul 2026 09:00:00 +0200</lastBuildDate><atom:link href="https://private.onlythoughts.io/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Quellen: Software Architecture FS26 (EIP, ESB &amp; Camunda)</title><link>https://private.onlythoughts.io/quellen/software-architecture-fs26-eip/index.html</link><pubDate>Fri, 10 Jul 2026 09:00:00 +0200</pubDate><guid>https://private.onlythoughts.io/quellen/software-architecture-fs26-eip/index.html</guid><description>Vorlesungs-Foliensatz und Camunda-7-Doku als Rohmaterial zu Enterprise Integration, Messaging und Workflow-Orchestrierung.</description></item><item><title>Platform Engineering: Cognitive Load, IDPs &amp; Abstraktionen</title><link>https://private.onlythoughts.io/konzepte/platform-engineering/index.html</link><pubDate>Thu, 28 May 2026 16:10:00 +0200</pubDate><guid>https://private.onlythoughts.io/konzepte/platform-engineering/index.html</guid><description>In den letzten Jahren hat sich der DevOps-Gedanke (“You build it, you run it”) in vielen Unternehmen als eine gewaltige Herausforderung entpuppt. Entwickler sollen nicht mehr nur exzellenten Java- oder C#-Code schreiben, sondern gleichzeitig Kubernetes-Cluster verwalten, Terraform-Skripte schreiben, CI/CD-Pipelines pflegen und sich um Security-Zertifikate kümmern.
Das Resultat? Ein massiver Anstieg des Cognitive Load (der kognitiven Belastung). Genau hier setzt Platform Engineering an.
1. Das Problem: Cognitive Load Jeder Mensch hat nur eine begrenzte Kapazität, Informationen im Arbeitsgedächtnis zu behalten. Wenn ein Entwickler-Team 40 % seiner Zeit damit verbringt, Infrastruktur-Fehler zu debuggen oder herauszufinden, wie man eine Datenbank provisioniert, fehlt diese Zeit für das eigentliche Ziel: Das Entwickeln von Business-Features.</description></item><item><title>Event-Driven Architecture: Kafka, Streaming &amp; CEP</title><link>https://private.onlythoughts.io/konzepte/event-driven-architecture/index.html</link><pubDate>Thu, 28 May 2026 15:25:00 +0200</pubDate><guid>https://private.onlythoughts.io/konzepte/event-driven-architecture/index.html</guid><description>In modernen Architekturen rückt die Verarbeitung von kontinuierlichen Datenströmen (“Data in Motion”) immer mehr in den Fokus. Dieser Post fasst die wichtigsten technischen Konzepte, Abgrenzungen und Frameworks rund um Event Streaming und Complex Event Processing (CEP) zusammen.
1. Message vs. Event Obwohl die Begriffe oft synonym verwendet werden, gibt es in der Architektur einen fundamentalen Unterschied bezüglich der Absicht des Senders:</description></item><item><title>The Software Architect Elevator - Notizen &amp; Zusammenfassung</title><link>https://private.onlythoughts.io/notizen/architecture-elevator-notes/index.html</link><pubDate>Fri, 24 Apr 2026 10:45:00 +0200</pubDate><guid>https://private.onlythoughts.io/notizen/architecture-elevator-notes/index.html</guid><description>In diesem Post archiviere ich meine iterativen Notizen und Zusammenfassungen zum Buch “The Software Architect Elevator” von Gregor Hohpe.
Das Kernkonzept des Buches: In grossen, komplexen Unternehmen (“Enterprises”) gibt es oft eine starke Trennung zwischen dem “Maschinenraum” (der IT / den Entwicklern) und dem “Penthouse” (dem C-Level / Management). Ein guter Softwarearchitekt muss den Fahrstuhl bedienen können und auf beiden Ebenen fliessend kommunizieren.
🏗️ Teil 1: Architects Kapitel 1: Architects Es ist oft einfacher zu beschreiben, was ein Softwarearchitekt nicht ist, anstatt eine exakte Definition für die Rolle zu finden.</description></item><item><title>Messaging Architecture: Sync/Async, MOM &amp; ESB</title><link>https://private.onlythoughts.io/konzepte/messaging-mom-esb/index.html</link><pubDate>Tue, 21 Apr 2026 16:40:00 +0200</pubDate><guid>https://private.onlythoughts.io/konzepte/messaging-mom-esb/index.html</guid><description>In verteilten Systemen (z.B. Microservices) ist die Kommunikation zwischen den einzelnen Komponenten oft die grösste Herausforderung. Wie stellen wir sicher, dass Systeme zuverlässig miteinander sprechen, ohne sich gegenseitig zu blockieren?
Hier kommen verschiedene Kommunikationsmuster (Synchron vs. Asynchron) und Middleware-Lösungen (MOM und ESB) ins Spiel. (Ich habe mich entschieden, alles in einem umfassenden Post zu bündeln, da die Konzepte fliessend ineinander übergehen!)
1. ☎️ Synchrones vs. Asynchrones Messaging Bevor man Systeme vernetzt, muss man sich für die Art der Kommunikation entscheiden. Beide Ansätze haben ihre Daseinsberechtigung.</description></item><item><title>SOLID Principles: Clean Code &amp; Design</title><link>https://private.onlythoughts.io/guides/solid/index.html</link><pubDate>Sat, 08 Feb 2025 12:35:44 +0100</pubDate><guid>https://private.onlythoughts.io/guides/solid/index.html</guid><description>SOLID ist ein Akronym für fünf grundlegende Prinzipien des objektorientierten Designs. Sie wurden von Robert C. Martin (Uncle Bob) geprägt und helfen dabei, Software zu entwickeln, die wartbar, erweiterbar und testbar ist.
1. Single Responsibility Principle (SRP) “A class should have one, and only one, reason to change.”
Was? Eine Klasse sollte nur eine einzige Aufgabe haben. Wenn eine Klasse mehrere Verantwortlichkeiten übernimmt, führt dies zu einer starken Kopplung und erhöht die Fehleranfälligkeit bei Änderungen.</description></item><item><title>The Architecture Compendium: Principles &amp; Patterns</title><link>https://private.onlythoughts.io/guides/architecture/index.html</link><pubDate>Fri, 07 Feb 2025 19:23:25 +0100</pubDate><guid>https://private.onlythoughts.io/guides/architecture/index.html</guid><description>This is a curated collection of fundamental software development principles, architectural patterns, and industry standards. It serves as a quick reference for designing robust and scalable systems.
1. Software Development Principles 🛠️ Fundamental rules for writing clean and maintainable code.
SOLID (Object-Oriented Design): The bedrock of OOP. Read my detailed post on SOLID. DRY (Don’t Repeat Yourself): Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. KISS (Keep It Simple, Stupid): Most systems work best if they are kept simple rather than made complicated. YAGNI (You Ain’t Gonna Need It): A principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. GRASP (General Responsibility Assignment Software Patterns): Nine basic principles in object-oriented design and responsibility assignment (e.g., Creator, Controller, Low Coupling, High Cohesion). 2. Software Architecture Patterns 🏗️ High-level structures used to organize software systems.</description></item></channel></rss>