wiwatsrt/laravel-property-management

1. This is a Laravel 5-style monolith for a property management agency. The app is split into a public-facing site and an authenticated admin back office, with most business functionality living in the admin area.

2. The main request path is standard Laravel: HTTP routes in app/Http/routes.php go through middleware in app/Http/Kernel.php, then into controllers. The admin section is handled by controllers under app/Http/Controllers/Admin, while authentication is handled separately under app/Http/Controllers/Auth.

3. The core business subsystems are:

- Property management

- Location management

- Zone location management

- Static page management

- Homepage slide management

- User management

- Site settings

4. Data access is organized with a repository layer. Each major admin domain has a repository under app/Repositories/Admin, backed by a shared BaseRepository. This sits between controllers and Eloquent models, so the architecture is controller → repository → model/database rather than controllers talking directly to models everywhere.

5. The data model is relational and intentionally normalized around multilingual content. Several entities have paired translation models and tables:

- Location / LocationTranslation

- ZoneLocation / ZoneLocationTranslation

- Page / PageTranslation

- Property / PropertyTranslation

This points to a translatable-content boundary where the base record stores shared attributes and translation tables store localized text.

6. Validation is separated from controllers through form request classes in app/Http/Requests/Admin and user-related request classes at the root. The flow is: route → controller → request validation → repository/model save. This keeps CRUD controllers thin and moves input rules into dedicated classes.

7. The admin UI is server-rendered Blade templates under resources/views/admin. The repeated create/edit/index/show/table/fields view structure suggests generated CRUD scaffolding. The UI uses the bundled AdminLTE theme in public/AdminLTE-2.3.3, with jQuery-based widgets such as DataTables, CKEditor, datepicker, Select2, and color picker.

8. Public presentation is also Blade-based, with shared layouts in resources/views/layouts and site pages like home.blade.php and auth views under resources/views/auth. The app is not an API-first service; it is a server-rendered MVC application.

9. File upload/storage is part of the architecture. Public upload directories exist for property and slideHomes, indicating image/media assets are stored on disk and then served from public/uploads/.... This is a distinct content pipeline from the database-backed records.

10. The property domain includes supporting enumerations and formatting helpers in app/Support, such as category, ownership, parking, swimming pool, type, view, and currency formatting. These are domain constants/utilities used to keep property metadata consistent across forms and views.

11. Internationalization is a first-class concern. Language files in resources/lang/en cover auth, validation, pagination, and each domain object. Combined with the translation tables and config/translatable.php, the app is built to render localized content per model, not just static UI text.

12. Infrastructure-wise, this is a conventional PHP/Laravel deployment: Composer-managed backend, Gulp/Node asset tooling, database migrations and factories, and Travis CI for build/test automation. Runtime behavior is mostly synchronous web request handling; queues, events, and jobs exist but are not central in this repository snapshot.

13. For an architecture diagram, the clearest boundaries are: browser/admin UI → Laravel HTTP layer → validation/repository/domain models → database, with a separate file-storage path for uploaded property and slideshow assets. The public site and admin console share the same backend but are functionally distinct entry points.