Software Design

1Concept / Definition

Software design is the activity — and the result — of deciding how a software system is organised into parts, what each part is responsible for, how parts interact and depend on each other, and which details each part hides. The outcome of design is a structure: modules, classes, interfaces, data models and the relationships between them.

Three properties characterise design decisions:

2Why It Exists

In the 1960s–70s software grew beyond what one person could hold in their head, and the "software crisis" — late, buggy, unmaintainable projects — made clear that writing correct statements was not enough. Structured design (Stevens, Myers and Constantine, 1974), information hiding (Parnas, 1972) and later object-oriented design (Booch, Meyer, Gamma et al.) introduced explicit ways of deciding structure. Agile practices (from 2001) did not abolish design; they made it continuous and evolutionary — "just enough" upfront, refined through refactoring.

3Core Concepts

3.1 What is software design?

Design answers four recurring questions for any piece of software:

Design operates under forces: functional requirements, quality requirements (performance, security), constraints (team, technology, deadline) and expected change. Good design balances these forces; there is no context-free "correct" design (Topic 1.4).

3.2 Design vs implementation

Implementation is the realisation of a design in code: algorithms, idioms, error handling, library usage. The two are intertwined but answer different questions.

// Design decision: price calculation is a separate, replaceable policy
public interface PricingPolicy {
    Money priceFor(Cart cart, Customer customer);
}
 
// Implementation decision: how this particular policy computes the price
public final class TieredPricingPolicy implements PricingPolicy {
    @Override
    public Money priceFor(Cart cart, Customer customer) {
        Money subtotal = cart.lines().stream()
                .map(CartLine::total)
                .reduce(Money.ZERO, Money::plus);
        return customer.isGold() ? subtotal.times(0.9) : subtotal;
    }
}

A correct implementation can sit inside a poor design (logic duplicated across five services), and a good design can have buggy implementations (fixed locally). Code reviews should examine both.

3.3 Design vs architecture

Architecture is the subset of design decisions that are significant — expensive to change, cross-cutting, or tied to key quality attributes. Grady Booch put it as: architecture represents the significant design decisions, where significance is measured by cost of change.

The boundary is fuzzy and context-dependent: choosing a date/time type is implementation in one class, but architecture if it defines the time model across fifty services.

3.4 Low-level design

Low-level design (LLD) specifies the inside of a component: classes, their fields and methods, relationships (association, composition, inheritance), algorithms and data structures, and the patterns applied. It is what interviewers mean by "design a parking lot" or "design an LRU cache".

// LLD sketch: Order aggregate with an invariant and intention-revealing methods
public final class Order {
    private static final int MAX_LINES = 50;
    private final OrderId id;
    private final List<OrderLine> lines = new ArrayList<>();
    private OrderStatus status = OrderStatus.DRAFT;
 
    public Order(OrderId id) { this.id = Objects.requireNonNull(id); }
 
    public void addLine(Product product, int quantity) {
        if (status != OrderStatus.DRAFT) {
            throw new IllegalStateException("Order not editable");
        }
        if (lines.size() == MAX_LINES) throw new IllegalStateException("Too many lines");
        lines.add(new OrderLine(product, quantity));
    }
 
    public Money total() {
        return lines.stream().map(OrderLine::total).reduce(Money.ZERO, Money::plus);
    }
 
    public void submit() {
        if (lines.isEmpty()) throw new IllegalStateException("Empty order");
        status = OrderStatus.SUBMITTED;
    }
 
    public List<OrderLine> lines() { return List.copyOf(lines); }
}

3.5 High-level design

High-level design (HLD) describes a system or subsystem in terms of components (services, modules, databases, external systems), their interfaces, and data and control flow between them. It sits between architecture and LLD and is what "system design" interviews focus on at component level.

4How It Works Internally — Design as a Process

1. Understand forces: requirements, quality goals, constraints, expected change.

2. Identify concepts from the domain (nouns, verbs, rules) and candidate responsibilities.

3. Assign responsibilities to components (HLD) and then classes (LLD) — keeping related responsibilities together and volatile decisions hidden.

4. Define interfaces between the parts, including contracts and error behaviour.

5. Validate with scenarios ("what if tax rules change?"), prototypes and tests.

6. Implement and refine: refactoring continuously improves the design as understanding grows.

Design proceeds top-down (decomposing a system) and bottom-up (extracting abstractions from working code) at the same time. Test-driven development is one technique that drives LLD from the caller's perspective.

4ADeep Dive — How Much Design Up Front?

A practical rule: decide up front what is expensive to change (service boundaries, data ownership, public APIs, persistence model) and let the rest emerge through TDD and refactoring. Record significant decisions in ADRs (Book 4, Topic 10.7).

4A.1 Design documentation that stays useful

5APIs / Features / Syntax — Java Features That Express Design

// A sealed hierarchy documents a design decision: exactly these payment types exist
public sealed interface Payment permits CardPayment, BankTransfer, Voucher { }
public record CardPayment(String token, Money amount) implements Payment { }
public record BankTransfer(String iban, Money amount) implements Payment { }
public record Voucher(String code, Money amount) implements Payment { }
 
Money fee(Payment p) {
    return switch (p) {                        // compiler checks exhaustiveness
        case CardPayment c -> c.amount().times(0.015);
        case BankTransfer b -> Money.of("0.20");
        case Voucher v -> Money.ZERO;
    };
}

6Practical Examples

6.1 One feature, four levels

6.2 Recognising a hidden design decision in code

// Before: design decision (tax rate) buried in implementation, repeated in 4 places
double total = subtotal * 1.19;
 
// After: decision made explicit and located in one place
public interface TaxPolicy { Money taxOn(Money net, Region region); }
Money total = net.plus(taxPolicy.taxOn(net, customer.region()));

6.3 LLD interview template

6.4 HLD review checklist

• Every component has a clear responsibility and owner.
• Every piece of data has exactly one owning component.
• Interfaces are documented with error behaviour and versioning.
• Main flows are shown as sequences, including failure paths.
• Quality requirements (latency, availability) are mapped to mechanisms.

7Common Problems & Mistakes

• Equating design with diagrams — diagrams drift; code is the truth.
• No design at all ("we're agile") — structure emerges accidentally and expensively.
• Designing for imagined futures — speculative generality (Topic 1.4).
• Mixing levels in one discussion — debating naming while service boundaries are undecided.
• Architecture by technology choice — picking frameworks before understanding responsibilities.
• Treating LLD as "just coding" — skipping responsibility assignment inside components.

8Performance & Production Considerations

Performance-critical paths are design decisions too: batching, caching and asynchronous processing are hard to retrofit if interfaces assume one item per synchronous call.

9Architecture & Design Considerations

• Architecture is design with a high cost of change — invest review effort accordingly.
• Keep levels consistent: HLD component boundaries should be visible in LLD packages and modules.
• Make design explicit in code: types, modules and names should reveal the intended structure.
• Evolve deliberately: refactor as understanding grows; record significant decisions.

10Interview Questions & Answers