Docs
Estimated time: 10 minutes
Difficulty: Intermediate

# Architecture

Estimated time: 10 minutes
Difficulty: Intermediate

LaraCoreKit is built on a modular architecture where each feature is isolated into a module with clear boundaries.

Architectural Goals

  1. Separation of concerns - Features are isolated.
  2. Scalability - Add new modules without touching core.
  3. Maintainability - Smaller, focused code areas.
  4. Reusability - Modules can be reused across projects.
  5. Testability - Module-level testing is straightforward.

High-Level Design

Application Core
├── Module Loader
├── Global Middleware
├── Shared Layouts
└── Cross-cutting Services

Feature Modules
├── Auth
├── User
├── Blog
├── Media
└── Settings

Core is intentionally minimal. Most business logic belongs in modules.

Request Lifecycle (Simplified)

  1. Request enters Laravel HTTP kernel.
  2. Global middleware runs.
  3. Routes resolve (core + module routes).
  4. Controller/Livewire from module executes.
  5. View or JSON response is returned.

Layering Strategy

Core Layer

  • Boots module system
  • Provides shared helpers/layouts
  • Coordinates application-level concerns

Module Layer

Each module owns:

  • Domain models
  • Routes/controllers/livewire
  • Admin resources
  • Migrations/seeders
  • Views/translations

Infrastructure Layer

  • Database, cache, queue, mail
  • Filesystem/media
  • External services

Why This Works Well

  • Teams can work in parallel by module.
  • New features are additive, not invasive.
  • Refactoring one feature has minimal side effects.
  • Optional modules can be distributed as packages.

Design Principles

  1. Keep app/ small and framework-centric.
  2. Keep feature code inside modules/{Feature}.
  3. Prefer explicit module contracts over hidden coupling.
  4. Avoid cross-module direct DB assumptions when possible.
  5. Use events/services for looser integration.

Typical Data Flow

Example: creating a blog post

  1. Authenticated user submits form.
  2. Blog module validates request.
  3. Blog model persists translated fields.
  4. Permission checks use shared RBAC system.
  5. Optional media attachments via Media module.
  6. Response returns to frontend/admin.

Trade-offs

Benefits

  • Better structure for medium/large apps.
  • Faster feature onboarding.
  • Cleaner ownership boundaries.

Costs

  • Slightly more setup for new modules.
  • Requires consistent conventions.
  • Developers must understand module boot process.

Next Steps

Next: Module System →