I'm trying to adopt the Layered Architectural Style. I imagine the Layered Architecture like it's drawn on this 
and I've got a PHP Laravel-based app. The app consists of:
-
The framework
-
A composer package - a set of independent interfaces on which everything else depends (dependency inversion)
-
A composer package - component manager. Depends on the interfaces package. Manages components - pieces of the pages (see the next point) consisting out of these components.
-
A composer package - page manager. Depends on the interfaces and components packages. Extracts JSON from the database and build HTML pages based on it using also the components package. The pages consist out of the components produced by the package from the point 2.
My questions are:
Can I call the set of interfaces a Service Layer? It's used in various places: controllers consumed by the frontend JS app (forward requests to the services implementing the interfaces), API consumed by mobile apps (forwards requests too) and so on - all depends on the interfaces. Or a Service Layer is something less thin? I mean does it have to have it's own implementation? Something like that: service layer interface, dependant service layer implementation which forwards requests down to the business layer.
The components described in the points 2 and 3 seem to be more of presentational layer components. But they implement the interfaces from the set described in the point 1. Is that ok? My confusion is that the service layer is lower than the presentation layer, by it forwards requests to the presentational layer (or it could forward if it had it's own implementation). Really confused here.
The business layer is currently missing. Is it true or the two packages (component and page services) are rather business components? They implement some logic of building pages.
The data layer is represented by the framework's components.
Could you help me guys with clarifying the things? Feel really confused about this.
via Sergey
