Über mich

Über mich

Ich bin David Michaelis — seit vielen Jahren im Frontend unterwegs: als Senior Developer, Tech Lead, Teamleiter und Frontend-Architekt.

Ich komme aus dem klassischen Frontend.

Aus einer Zeit, in der man Webseiten noch mit langen CSS-Sessions bunt machte, Layouts mühsam geradezog und ein großer Teil der Arbeit darin bestand, Pixel, Browser und Erwartungen irgendwie miteinander zu versöhnen.

Anfang der 2000er war Frontend oft Oberfläche. Viel Gestaltung. Viel Handarbeit. Viel Improvisation.

Und ja: Auch das war Handwerk.

Aber über die Jahre wurde aus „bunte Seiten bauen“ etwas anderes.

Frontends wurden zu echten Anwendungen. Mit komplexem Zustand. Mit Geschäftsregeln. Mit Sicherheitsanforderungen. Mit Rollen und Rechten. Mit regulatorischen Erwartungen. Mit Teams, die über Jahre daran arbeiten. Mit Systemen, die nicht nur funktionieren, sondern tragfähig bleiben müssen.

Ich habe in verschiedenen Startups gearbeitet und später mehr als eine Dekade in einem großen Softwarekonzern, der im regulierten Umfeld medizinische Software gebaut hat.

Dort habe ich gelernt, dass Frontend nicht nur Pixel schubsen ist.

Frontend ist harte Applikationsentwicklung.

Und gute Frontend-Entwicklung braucht Disziplin, Architektur, fachliches Verständnis und handwerkliches Geschick.

Mein Blick auf Architektur

Mein Schwerpunkt liegt im Frontend, aber mein aktueller Blick ist nicht mehr rein frontend-zentriert.

Moderne Frontend-Architektur endet selten an der Komponentengrenze.

Sie berührt Build-Systeme, Monorepos, APIs, Deployment-Strategien, Teamgrenzen, fachliche Schnitte, Testbarkeit, Observability und manchmal auch die Frage, ob ein System überhaupt richtig geschnitten ist.

Deshalb beschäftige ich mich heute nicht nur mit Komponenten, Stores und UI-Patterns, sondern auch mit größeren Systemzuschnitten:

• Self-contained Systems
• Microfrontends
• Module Federation
• API- und Service-Grenzen
• Event-getriebene Kommunikation
• Preview-/Branch-Deployments
• CI/CD in Nx-Monorepos
• Architektur in regulierten Kontexten
• Integration von LLMs und agentischen Entwicklungsflüssen

Frontend bleibt mein Schwerpunkt.

Aber die spannendsten Fragen entstehen oft dort, wo Frontend, Backend, Teamstruktur und Deployment aufeinandertreffen.

Womit ich arbeite

Technisch bewege ich mich vor allem in modernen TypeScript- und Angular-Ökosystemen.

Dazu gehören unter anderem:

• Angular in größeren Enterprise-Setups
• Nx Monorepos und klare Projektgrenzen
• Module Federation und Micro-Frontend-Architekturen
• Self-contained Systems als fachlich geschnittene Systembausteine
• Domain-Driven Design im Frontend
• vertikale Schnitte statt technischer Ordnerfriedhöfe
• NgRx, Signal Store und reaktive Datenflüsse
• NestJS und API-Gateways im TypeScript-Umfeld
• E2E-Strategien mit Playwright
• Branch-/Preview-Deployments
• Docker, Traefik und GitLab CI/CD
• Architektur in regulierten Kontexten
• LLM-Integration als eigener Service

Tools sind dabei nicht der Kern.

Tools sind nur dann hilfreich, wenn sie gute Schnitte unterstützen.

Ein Store löst kein State-Problem, wenn niemand weiß, welcher Zustand fachlich ist. Ein Microfrontend macht kein Team autonom, wenn die fachlichen Grenzen fehlen. Ein Monorepo ist keine Architektur, wenn alles mit allem sprechen darf. Ein SCS ist kein Gewinn, wenn Verantwortung, Daten, UI und Betrieb nicht zusammen gedacht werden.

Was ich erlebt habe

Ich habe Systeme gesehen, die über Jahre tragfähig geblieben sind.

Systeme, in denen klare Grenzen geholfen haben, neue Anforderungen einzuordnen. Systeme, in denen Tests Mut gemacht haben. Systeme, in denen Architektur nicht nur im Diagramm existierte, sondern im Code sichtbar war.

Und ich habe Systeme gesehen, bei denen genau das fehlte.

Komponenten, die alles wussten. Services, die zu kleinen Betriebssystemen wurden. Stores, die alles machten, nur nichts richtig. Microfrontends, die keine Autonomie erzeugten, sondern verteilte Kopplung. Architektur, die erst gerufen wurde, als es schon brannte.

Diese Mischung prägt meinen Blick.

Ich glaube nicht an Architektur als Selbstzweck. Aber ich glaube sehr daran, dass gute Architektur Teams entlastet.

Sie macht nicht alles einfach.

Aber sie macht Veränderung weniger zufällig.

Diese Seite

frontend-architekt.de ist mein öffentliches Arbeitsbuch.

Eine Sammlung von Haltungen, Patterns, Anti-Patterns, Architekturentscheidungen und Feldberichten aus echter Projektarbeit.

Nicht als neutraler Best-Practices-Blog. Nicht als Framework-Fanclub. Nicht als Marketing-Funnel.

Sondern als Versuch, Frontend-Architektur so zu beschreiben, wie sie mir in echten Projekten begegnet:

technisch, organisatorisch, manchmal unbequem — aber immer mit dem Ziel, Systeme verständlicher, wartbarer und veränderbarer zu machen.

Kontakt

Wer Kontakt aufnehmen möchte:

info@david-michaelis.de