Layer Boundaries and Dependencies

The intended architecture is described on Architecture Overview. This page measures what the imports actually do, and lists every place the two disagree.

Every `use` statement that resolves to a first-party class, counted by the layer that wrote it and the layer that declares the target. 503 imports across 28 distinct layer pairs.

Read it as a graph and five cycles are immediately visible:

• core ↔ controller — `controller → core` 122, `core → controller` 5
• core ↔ handler — `handler → core` 48, `core → handler` 46
• core ↔ dao — `dao → core` 25, `core → dao` 15
• core ↔ model — `model → core` 16, `core → model` 5
• core ↔ service — `service → core` 47, `core → service` 7

A cycle is only a design problem if the dependency carries *behaviour*. Most of `core`'s upward reach is concentrated in the two files whose entire job is to know about every other layer.

`core → handler` is not a layering defect. 45 of its 46 imports sit in `Bootstrap.php`, and `Bootstrap` is the composition root: it exists to instantiate the handler registry. Reading a cycle through the composition root is a category error.

Two upward dependencies are *not* explained that way, and are the real findings:

• `lib/core/AtomWriter.php → model` (2 imports, `FrontContentModel` and `PostModel`). Atom generation is a `core` class reaching into the domain model. This is a genuine upward edge in a leaf-ish class.
• `lib/core/Authentication.php → dao` (2 imports, `UserDao` and `UserTokenDao`). Authentication is a `core` class that queries the data layer directly rather than going through a service, so it carries SQL concerns that belong one layer up.

The DAO layer's own description claims: *“No HTML, no session, no superglobals.”* Measured against comment-stripped source:

• The DAO rule is almost kept. Two `$_POST` mentions across 19 DAO files is the whole violation, and neither is a query input.
• `model` and `validator` are completely clean — zero superglobal mentions in either.
• The “only controllers read superglobals” claim is badly wrong. The controller layer is the worst offender at 854, but `utility` (215), `core` (178) and `admin` (292) all reach into global state too, and `admin` is not a controller at all.
• `service` is the surprise: it reads `$_POST` 48 times while claiming no superglobal access. Business logic that reads request data directly cannot be called from a non-HTTP context — a cron job, a CLI import or a test cannot supply `$_POST`.

Counts are of comment-stripped source, but string literals are still counted, so treat them as *mentions* rather than proven reads.

• The deprecated facade is a soft boundary. `Scriptlog\Core\FrontHelper` delegates to `FrontService` when `Bootstrap` has registered one, and returns `null` or an empty array when it has not. Nothing raises; a missing registration degrades into empty output rather than an error.
• The `handler` layer reaches back up once. `lib/handler/DownloadHandler.php` imports `Scriptlog\Controller\DownloadController`, the only `handler → controller` edge in the tree.
• `service` depends on `utility` (8 imports) for the export feature: `ExportService` imports `BlogspotExporter`, `GhostExporter` and `ScriptlogExporter`. A service layer importing flat procedural helpers is the boundary most likely to be crossed by a new contributor, because `lib/utility/` is unnamespaced and looks like a neutral dumping ground.
• `admin/` is procedural, not namespaced. Its 103 files include `admin/ui/**` templates that declare no classes at all, so the admin UI has no layer boundary to lean on.

• Architecture Overview
• Limits and Non-behaviour
• Negative Space and Dead Code