PHPackages cyberma/laravel-layer-frame - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Framework](/categories/framework) 4. / 5. cyberma/laravel-layer-frame ActiveProject[Framework](/categories/framework) cyberma/laravel-layer-frame =========================== Layer Frame for Laravel 1.12.2(3mo ago)2442MITPHPPHP >=8.2 Since Nov 27Pushed 3mo agoCompare [ Source](https://github.com/cyberma-net/laravel-layer-frame)[ Packagist](https://packagist.org/packages/cyberma/laravel-layer-frame)[ RSS](/packages/cyberma-laravel-layer-frame/feed)WikiDiscussions master Synced 1mo ago READMEChangelog (10)Dependencies (3)Versions (46)Used By (0) Layer Frame for Laravel ======================= [](#layer-frame-for-laravel) ### A scalable, layered architecture for large Laravel projects [](#a-scalable-layered-architecture-for-large-laravel-projects) Motivation ---------- [](#motivation) Laravel's native Active Record (Eloquent) is fantastic for small and medium-sized projects — but it becomes problematic at scale: - Models grow huge and violate Single Responsibility Principle (SRP) - Business logic ends up scattered across Controllers, Models, Traits, and global helpers - Tight coupling between database schema and business logic makes refactors dangerous - Testing large models becomes painful - Database structure leaks into the rest of the codebase Layer Frame solves these issues by introducing a strict, layered, dependency-flow and complete separation between: - your business logic - your internal domain models - your database schema - your input / API formats This comes at the cost of more classes, but brings massive benefits: - refactoring safety - better testability - cleaner responsibilities - fully DB-agnostic data layer - predictable code structure - safer long-term evolution of the project Core Principles --------------- [](#core-principles) Layer Frame is built around a few objective architectural rules: 1. **Layered structure (no jumping across layers)**Each layer communicates only with the one directly below or above it. No Controller → DB, no Service → DBStorage, no random SQL inside Services. 2. **Composition over inheritance**Small composable objects instead of monolithic Models or deep inheritance trees. 3. **Configuration over copy-pasted code**Almost everything is controlled via simple configuration arrays: - ATTRIBUTES\_MAP - PRIMARY\_KEY - JSON\_COLUMNS - COLUMN\_ALIAS\_MAP - MANDATORY\_ATTRIBUTES 4. **90% typical flows must be easy**Simple CRUD is nearly automatic. 5. **The remaining 10% must be fully customizable**Every layer has extension points for special logic. 6. **Strict SRP + SOLID**No class should do more than one job. 7. **Infrastructure-agnostic**DB storage can be swapped, mappings changed, and API formats redesigned without breaking the rest of the code. Layer Overview -------------- [](#layer-overview) ### Controllers [](#controllers) - Validate incoming data - Map inputs to InputModels - Call a Service method - Map results to API shape (using ApiMapper) - Return JSON Controllers do zero business logic. Helpers included: - Paginator - Searcher For consistent pagination & search interfaces. ### Input Models [](#input-models) Represent incoming request structure. Inside each InputModel: - Validation rules - Custom messages (optional) - doExtraValidations() hook InputModel is the only place that "knows" the shape of incoming data. ### Input Parsers [](#input-parsers) InputParser performs: - Validation (Laravel Validator) - Extra validations (custom) - Filling the model attributes safely InputParser is generic; you rarely need a custom implementation. ### Services [](#services) Services contain all business logic. A Service: - receives clean InputModels or Models - orchestrates Repositories - applies domain rules - returns domain Models Services never talk to the database directly. ### Repositories [](#repositories) Repositories form the boundary between business logic and persistence. A Repository uses: - ModelMap (attribute → column map) - DBMapper (model attributes ↔ DB row mapping) - DBStorage (actual SQL operations) - ModelFactory (model instantiation) Purpose: - Convert IModel → array for insert/update (via DBMapper) - Convert DB rows → Models (via DBMapper) - Execute standard DB operations via DBStorage Unlike Eloquent: - No "magic queries" - No Active Record domain pollution - Fully independent of SQL schema Repositories support: - get / first / count - search - store - delete - patch - composite keys All without exposing SQL to the Service. ### DBMapper [](#dbmapper) Maps between: - Layer Frame Model attributes ↔ SQL column Responsibilities: - Attribute→column mapping - Column→attribute mapping - JSON encoding/decoding - Automatic primary key handling - Custom mapping hooks - Normalizing conditions - Default value transformations DBMapper is the translator between your domain model and the raw DB. ### DBStorage [](#dbstorage) The only class that actually touches SQL. Capabilities: - Select / count - Update / insert / patch - Composite primary key support - Soft deletes - Pagination - WHERE operator normalization: `=`, `=`, ``, etc. DBStorage is fully generic. It never knows anything about your Models or your domain. ### Models [](#models) Domain objects representing your internal state. They are not Eloquent models. Features: - Magic \_\_get/\_\_set with attribute registry - Dirty tracking - hydrate() vs set() - hydrate() sets internal state without marking dirty - set() marks dirty attributes - toArray() for exporting - setMany() / getMany() Models contain zero DB logic, zero validation, zero business logic. ### Model Maps [](#model-maps) Declarative mapping: ``` const TABLE = 'users'; const PRIMARY_KEY = ['id']; const ATTRIBUTES_MAP = [ 'id' => 'id', 'firstName' => 'first_name', 'lastName' => 'last_name', 'roles' => 'roles_json', ]; ``` ModelMap controls: - Table name - Attribute→column mapping - Hidden columns - JSON columns - Composite primary keys - Mandatory attributes - Column aliases for JOINs - Primary key auto-increment behavior - Custom mapping & demapping hooks - per-table DB error interpretations ModelMaps enable DB independence. ### API Mapper [](#api-mapper) Converts a Model or collection of Models into a pure array ready for JSON encoding. Supports: - Renaming attributes for API - Custom attribute-specific callbacks - Filtering fields (API Map) This is where you shape your external API format. ### Exceptions [](#exceptions) Layer Frame uses: - CodeException – structured domain exception with LF code A central Handler that: - Translates CodeExceptions to clean JSON responses - Handles HTTP codes - Normalizes output format All exceptions have a code format like: `lf21XX` This allows tracking and error reporting across the system. Data Flow Summary ----------------- [](#data-flow-summary) ``` Request JSON ↓ InputParser → InputModel ↓ Service (business logic) ↓ Repository ↓ ↓ DBMapper ← DB rows ↓ DBStorage (SQL) ``` Reverse direction brings data back mapped to Models, then to APIMapper, then to JSON. Advantages Over Eloquent ------------------------ [](#advantages-over-eloquent) - **Massive refactor-safety**Renaming columns, restructuring the DB, or introducing composite keys does not require hunting through dozens of Model methods and queries. - **Full control over queries**No hidden Eloquent magic — SQL is predictable. - **Perfect testability**Mock DBStorage or DBMapper easily. - **Clear responsibilities**No more fat models or controllers. - **Independent data layers**Change DB engine or schema without rewriting business logic. When to Use Layer Frame ----------------------- [](#when-to-use-layer-frame) Layer Frame is ideal when you have: - A big project with a long life-cycle - Multiple team members - Frequent refactoring - Complex business logic - High testability requirements - Domain-driven design orientations - Microservice-like components inside a monolith Not recommended for tiny CRUD apps — Eloquent is fine there. --- 🔷 DOMAIN LAYER -------------- [](#-domain-layer) This is your business model of a filesystem. It includes: ### ✔ Entities (Folder, File, Storage, Permissions) [](#-entities-folder-file-storage-permissions) They: - enforce invariants ("folder must belong to storage") - have no DB knowledge - don't know about filesystem drivers - don't know about SQL or JSON ### ✔ Value Objects [](#-value-objects) - Path - Filetype - PermissionSet - StorageConfig ### ✔ Domain Services [](#-domain-services) - Permission checking - Path building - Name normalization - Storage rules - Quota rules ### ✔ Domain Factories [](#-domain-factories) - FolderFactory - FileFactory Convert attributes + context → domain objects. ### ❌ Domain Rules [](#-domain-rules) - Domain NEVER talks to DB - Domain NEVER calls Laravel's container - Domain NEVER performs I/O 🔷 INFRASTRUCTURE LAYER ---------------------- [](#-infrastructure-layer) This is everything about how and where data is stored or retrieved. ### ✔ DB Mappers [](#-db-mappers) Convert DB rows → attribute arrays (no business rules, no domain objects) ### ✔ Storage Adapters [](#-storage-adapters) Local disk or S3 are infrastructure concepts. ### ✔ Repositories (in DDD sense) [](#-repositories-in-ddd-sense) Repositories straddle application + infrastructure, but mostly infrastructure: - they talk to DB - use mappers - load storage from DB - resolve permissions - → then produce full domain models ### ✔ FS Adapters [](#-fs-adapters) Flysystem, local storage, S3 implementations ### ✔ Database Queries and SQL [](#-database-queries-and-sql) ### ❌ Infrastructure Rules [](#-infrastructure-rules) - Infrastructure must NOT enforce domain rules - (e.g., "user can't access this folder" belongs in domain/application, not DB mapper) --- Last update: 13th December 2025. ### Health Score 47 — FairBetter than 94% of packages Maintenance81 Actively maintained with recent releases Popularity17 Limited adoption so far Community6 Small or concentrated contributor base Maturity68 Established project with proven stability Bus Factor1 Top contributor holds 100% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~18 days Recently: every ~11 days Total 45 Last Release 99d ago PHP version history (2 changes)1.0.0PHP >=8.0 1.0.4PHP >=8.2 ### Community Maintainers ![](https://www.gravatar.com/avatar/03d99f7142f4c4764105b2f498dc4903665c8a87e20574227aada7db83b40602?d=identicon)[pmatisko](/maintainers/pmatisko) --- Top Contributors [![pmatisko](https://avatars.githubusercontent.com/u/35735922?v=4)](https://github.com/pmatisko "pmatisko (2 commits)") --- Tags laraveldata mapperLayer frame ### Code Quality TestsPHPUnit ### Embed Badge ![Health badge](/badges/cyberma-laravel-layer-frame/health.svg) ``` [![Health](https://phpackages.com/badges/cyberma-laravel-layer-frame/health.svg)](https://phpackages.com/packages/cyberma-laravel-layer-frame) ``` ### Alternatives [laravel/nightwatch The official Laravel Nightwatch package. 3486.1M13](/packages/laravel-nightwatch)[codewithdennis/larament Larament is a time-saving starter kit to quickly launch Laravel 13.x projects. It includes FilamentPHP 5.x pre-installed and configured, along with additional tools and features to streamline your development workflow. 3691.5k](/packages/codewithdennis-larament)[kompo/kompo Laravel & Vue.js FullStack Components for Rapid Application Development 11812.4k21](/packages/kompo-kompo) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)