What Low-Level Design Is

What Low-Level Design Is — Tech Epitome

The layer in between

System design decides which services exist and how they communicate. Programming decides which statements run. Low-level design is the layer between them: given one service, what types live inside it, what is each one responsible for, and how do they reach one another.

Concept

The question LLD answers

When this requirement changes — and you should be able to name which one will — how many classes have to be opened, and does the compiler tell you about all of them?

That framing is more useful than "is this design clean", because cleanliness is a matter of taste and the number of files you have to edit is not. Two designs can both look tidy; only one of them makes tomorrow's change a single new class.

Design is about anticipated change

There is no design that is best in the abstract. A parking garage with one fixed price needs no pricing abstraction, and adding one is not foresight — it is a guess dressed as architecture. The same abstraction becomes obviously right the moment a second pricing rule is on the roadmap.

If this is likely to change	Put a seam here
How something is priced, scored, or ranked	Behind an interface the caller holds
Which external system is called	Behind an interface your code defines
What kinds of a thing exist	Behind a common supertype
What happens after an event	Behind a listener or handler list
Nothing you can name	Nowhere — write the straightforward code

Seams are bets on change. Place the ones you can justify.

What you are actually deciding

Which things exist as types at all, and which are just fields on something else.
What each type is the only thing that knows.
Which types know about which others, and in which direction.
Which of those relationships go through an abstraction and which are direct.
What is fixed at construction and what can change at runtime.