This module’s last lesson no longer looks at single classes but at the whole Kladde: which project knows which? The D in SOLID, the dependency inversion principle, is often shortened to “program against interfaces”. What’s meant is something more precise: dependencies point to abstractions, and the abstraction belongs to whoever needs it. The Kladde’s core describes what it needs from outside as a port. The edges, database, TED, mail, web, fulfill these ports as adapters. The core knows none of them.
You’ve known this since lessons 1.4.6 and 2.4.11. In this lesson you check whether it still holds in your Kladde after fourteen modules, turn a wrong direction around, and have a test keep watch so it stays that way.
Direction instead of interfaces
An example makes the difference clear. The nightly import reads tenders from TED (Tenders Electronic Daily; lesson 2.8.2). Two ways to build it:
The wrong way around: the core holds the rule for which tenders interest the office. It works with the record TedNotice the way it
comes out of TED’s JSON, and TedNotice lives in Kladde.Ted. So Kladde.Core references Kladde.Ted. There’s an interface anyway,
say ITedClient in Kladde.Ted. The core now depends on TED: if TED changes its format, the core changes, and a test of the rule needs
the project with the HTTP client.
The right way around: the core describes what it needs in its own language: a record Tender with number, title, deadline and CPV
codes, and the port ITenderSource from lesson 2.8.1, which delivers Tenders. Kladde.Ted references the core, implements the port and
translates TED’s JSON into Tenders. If TED changes its format, only the adapter changes.
Both times there’s an interface. The difference is who owns it and where the arrow points. That’s the “inversion”: without the port, the arrow pointed from the core to the technology; with it, it points from the technology to the core. In K4, this way of building with ports and adapters is called hexagonal architecture (lesson 4.3.5); the idea is the same.