Pia

There is one real structural difference and it is entirely about which way the dependencies point.

In a classic layered architecture, each layer depends on the one below it. Presentation depends on services, services depend on data access, data access depends on the database driver. The dependency arrows all run downward, which means your business logic depends on your persistence layer.

In hexagonal, the core depends on nothing. It defines an interface describing what it needs — "something that can store an order" — and the database adapter implements that interface. The arrow now points inward, from the adapter to the core, which is the reverse of the layered version.

That single change is the whole idea, and everything else follows from it. If your layered code has the service layer importing a repository interface that lives in the data access layer, you have layers. If the interface lives with the business logic and the data access code implements it, you have hexagonal — regardless of what you call the folders.

Two cases where the answer changes, worth checking first:

The project has a contributing guide that says otherwise. Some projects ask for an issue first, or have a policy about documentation changes. Thirty seconds of reading saves an awkward exchange.

It is not actually a typo. Be careful with regional spelling differences, technical terms that look wrong but are not, deliberate stylisation of a product name, and text in a language you do not speak natively. "Correcting" British spelling to American, or a domain term to the ordinary word, is a small insult rather than a contribution.

When I am unsure whether something is a typo or a choice, I leave it. The ones I am confident about are worth fixing and the ones I am not are worth nothing.

And the answer to your second question is that he was being pedantic, and slightly wrong as well.

Most programs are not one algorithm. A typical application is mostly plumbing: reading configuration, handling requests, mapping between representations, calling libraries, formatting output. Very little of it is an algorithm in the technical sense, and calling a whole program "an algorithm" is a stretch that the word does not support.

"Code" is the correct and ordinary term for what you write, is used universally by people who do it professionally, and has been for decades. It is not slang and it is not imprecise.

My guess about what happened: in some older engineering education, particularly outside computer science, the word people learned was algorithm, and "code" was not part of the vocabulary. He was not correcting you so much as reporting that your word was unfamiliar to him.

Worth adding why this vocabulary is rare outside safety-critical work: in ordinary software, corruption is usually indistinguishable from a bug because nobody is looking.

A server that misbehaves once and never again gets restarted, and the incident is closed as unexplained. Nobody checks whether the memory image differed from the binary. With error-correcting memory in most server hardware, the events are also rarer and often silently corrected.

So the distinction exists everywhere and is only investigated where the consequences justify the cost of investigating.

One practical technique that gets most of what you want today: put the explanation on the type or the function, not on the variable, and keep variable names short.

Type and function documentation is read by the tooling, shown on hover at every use, and lives next to the thing it describes. Then rate inside a function whose signature and doc comment explain everything is perfectly readable, and you have not invented anything.