Skip to content
IRC-Coding IRC-Coding
Top-Down Bottom-Up Meet in the Middle Schnittstellen Kopplung Kohäsion

Top-Down vs. Bottom-Up Entwurf: Unterschiede, Risiken, Meet-in-the-Middle (IHK)

Top-Down startet bei Zielen/Use Cases und zerlegt in Komponenten. Bottom-Up setzt aus vorhandenen Bausteinen zusammen. Mit Kopplung/Kohäsion, Testbarkeit, Wirtschaftlichkeit und Prüfungsfragen.

S

schutzgeist

2 min read

Top-Down-Entwurf vs. Bottom-Up-Entwurf

Dieser Beitrag ist eine Begriffserklärung zu Top-Down vs. Bottom-Up – inklusive Prüfungsfragen, Kernkomponenten und Tags.

In a Nutshell

  • Top-Down beginnt bei fachlichen Zielen und zerlegt schrittweise in Teilprobleme und Schnittstellen.
  • Bottom-Up startet bei vorhandenen Bausteinen (Libs/Frameworks/Services) und setzt daraus eine Lösung zusammen.

In der Praxis ist oft Meet in the Middle sinnvoll.

Kompakte Fachbeschreibung

Top-Down

  • Zuerst Ziele, Kontext, Use Cases
  • Dann Verfeinerung: Subsysteme → Komponenten → Klassen → Operationen
  • Vorteil: klare fachliche Schnitte, gute Testableitung aus Anforderungen

Bottom-Up

  • Zuerst Wiederverwendung: Bibliotheken, SDKs, Frameworks, vorhandene Systeme
  • Dann Komposition + Adaption
  • Vorteil: schneller Start, geringerer Implementierungsaufwand

Risiken:

  • Top-Down: technische Randbedingungen werden zu spät sichtbar
  • Bottom-Up: technikgetriebene Architektur, Integrationskosten, Vendor Lock-in

Prüfungsrelevante Stichpunkte

  • Definitionen sauber abgrenzen
  • Kopplung gering halten, Kohäsion hoch
  • Schnittstellen stabil definieren
  • Traceability: Anforderung → Entwurf → Test
  • Adapter/Anti-Corruption Layer für externe Komponenten
  • Meet in the Middle als realistische Kombi

Kernkomponenten

  1. Fachliche Ziele + Kontext
  2. Zerlegung in Subsysteme
  3. Schnittstellenverträge
  4. Identifikation vorhandener Komponenten
  5. Adapter/Fassade/ACL
  6. Qualitätsziele/Architekturregeln
  7. SOLID/GRASP als Leitplanken
  8. Teststrategie (Akzeptanz → Unit)
  9. Security/Dependency-Checks/Lizenzen
  10. ADRs (Entscheidungen versionieren)

Praxisbeispiel (Zahlungsabwicklung)

Top-Down:
- Ziel: Zahlungen sicher autorisieren
- Services: Zahlungsservice, Bestellservice
- Ports: autorisiere(), storniere()

Bottom-Up:
- Vorhanden: Payment-SDK, HTTP-Client, Event-Bus
- Adapter kapselt SDK
- Contract Tests gegen Sandbox

Meet in the Middle:
- fachliche Ports definieren
- konkrete Adapter mit SDK füllen

Vorteile und Nachteile

Top-Down

  • Vorteile: klare Fachstruktur, stabile Ports, gute Testbarkeit
  • Nachteile: Anlaufphase, Technikrisiken können spät erscheinen

Bottom-Up

  • Vorteile: schnelle Ergebnisse, hohe Wiederverwendung
  • Nachteile: Gefahr technikgetriebener Schnitte, Integrations-/Lock-in-Risiko

Typische Prüfungsfragen (mit Kurzantwort)

  1. Grundunterschied? Top-Down zerlegt vom Ziel, Bottom-Up baut aus Bausteinen.
  2. Wie beeinflusst das Kopplung/Kohäsion? Top-Down stärkt fachliche Kohäsion; Bottom-Up kann Kopplung erhöhen.
  3. Wie kombiniert man sinnvoll? Meet in the Middle + Adapter + ADRs.

Lernstrategie

  1. Für eine Mini-Domäne beide Skizzen zeichnen.
  2. Ports als Interfaces definieren.
  3. Contract Tests gegen externe Komponenten üben.

Wichtigste Quellen

  1. https://refactoring.guru/design-patterns/adapter
Zurück zum Blog
Share:

Ähnliche Beiträge