Top-Down vs. Bottom-Up Design

This post is a conceptual overview of Top-Down vs. Bottom-Up – including exam questions, core components, and key terms.

In a Nutshell

• Top-Down starts with business goals and progressively breaks them into subproblems and interfaces.
• Bottom-Up starts with existing building blocks (libraries, frameworks, services) and assembles a solution from them.
• In practice, Meet in the Middle often makes the most sense.

Compact Technical Description

Top-Down

• Begin with goals, context, and use cases
• Then refine: subsystems → components → classes → operations
• Advantage: clear business boundaries, straightforward test derivation from requirements

Bottom-Up

• Begin with reuse: libraries, SDKs, frameworks, existing systems
• Then compose and adapt
• Advantage: faster start, lower implementation overhead

Risks:

• Top-Down: technical constraints emerge too late
• Bottom-Up: architecture driven by technology, integration costs, vendor lock-in

Exam-Relevant Points

• Define boundaries cleanly
• Keep coupling low, cohesion high
• Define stable interfaces
• Traceability: requirement → design → test
• Use adapters or anti-corruption layers for external components
• Meet in the Middle as a realistic combination

Core Components

1. Business goals and context
2. Decomposition into subsystems
3. Interface contracts
4. Identification of existing components
5. Adapters/facades/ACLs
6. Quality attributes and architecture rules
7. SOLID and GRASP as guides
8. Test strategy (acceptance → unit)
9. Security, dependency checks, licenses
10. ADRs (versioned decisions)

Practical Example (Payment Processing)

Top-Down:
- Goal: securely authorize payments
- Services: payment service, order service
- Ports: authorize(), cancel()

Bottom-Up:
- Available: payment SDK, HTTP client, event bus
- Adapter wraps SDK
- Contract tests against sandbox

Meet in the Middle:
- define business ports
- fill concrete adapter with SDK

Strengths and Weaknesses

Top-Down

• Strengths: clear business structure, stable ports, good testability
• Weaknesses: ramp-up time, technical risks can surface late

Bottom-Up

• Strengths: fast results, high reuse
• Weaknesses: risk of technology-driven boundaries, integration and lock-in hazards

Typical Exam Questions (with Brief Answers)

1. What’s the core difference? Top-Down decomposes from the goal; Bottom-Up builds from blocks.
2. How does it affect coupling and cohesion? Top-Down strengthens business cohesion; Bottom-Up can increase coupling.
3. How do you combine them wisely? Meet in the Middle plus adapters plus ADRs.

Learning Strategy

1. Sketch both approaches for a small domain.
2. Define ports as interfaces.
3. Practice contract tests against external components.

Key Sources

1. https://refactoring.guru/design-patterns/adapter