Projects using Laravel in SuratProjects using Laravel in Surat
Projects
People
Cover image for 🚀 Laravel Modular Development: Internal
🚀 Laravel Modular Development: Internal Modules or Reusable Packages? As a Laravel application grows, keeping everything inside the default Models, Controllers and Services directories can make the codebase difficult to maintain. This raises an important question: Should we create modules inside one Laravel application or develop separate Laravel packages? Both approaches are useful—but at different stages. 1️⃣ Start Simple During early development, requirements frequently change. A conventional Laravel structure helps us build faster without prematurely defining package boundaries. ⚠️ However, starting simple should not mean placing all business logic inside controllers. Services, actions, events, contracts and policies should still separate responsibilities. 2️⃣ Modularize as the Application Grows Once domain boundaries become clear, related code can be moved into internal modules such as: ✔️ Identity and Access Control ✔️ Catalog ✔️ Listings and Moderation ✔️ CMS and Form Builder ✔️ Monetization ✔️ Search, Analytics and SEO Each module can own its models, migrations, routes, controllers, services, requests, policies, events, enums, seeders and tests. Modules should communicate through ✅ services, contracts or events instead of ❌ accessing one another’s internal implementation. This creates a modular monolith: strong separation while retaining the simplicity of developing and deploying one application. 3️⃣ Let the First Application Reveal Patterns While building the first application, it is difficult to predict which components will be reusable. Something that appears generic may eventually depend heavily on product-specific rules, workflows or database structures. Completing the first application reveals the real module boundaries. 4️⃣ Confirm Reuse in Another Application When building a second application, repeated patterns become visible. A module may be suitable for extraction when: ♻️ Multiple applications require it. 🔁 Its core behaviour remains similar. ⚙️ Differences can be configured. 🔌 It provides a stable public API. 🧩 It has few application-specific dependencies. 📦 Independent versioning provides value. A Form Builder, Media Manager, Audit Log or Payment Gateway abstraction may become a reusable package. However, marketplace-specific Listings, Dealers or Moderation modules may remain internal because their rules are closely connected to that product. 🛠️ Practical Progression Conventional Laravel Application ➡️ Internal Domain Modules ➡️ Modular Monolith ➡️ Reuse Confirmed ➡️ Reusable Laravel Package 💡 My preferred principle: “Start simple, modularize when boundaries become clear, and extract packages only when reuse is proven.” The first application reveals the boundaries. The second proves what is genuinely reusable. 🎯 Reuse should be observed—not predicted. How do you structure large Laravel applications: internal modules, packages or both?
0
22
Cover image for DeskMint is being developed to
DeskMint is being developed to centralize client communication, manage invoices, and securely store documents in an encrypted vault, helping companies keep interactions and data organized and transparent. Notable features Dynamic custom fields with user-defined data models (structure + data, not just values) Bank-grade auth with token system and device fingerprinting Custom DataTable handling static and dynamic datasets Modular architecture using dependency injection and traits Granular field visibility, universal field ordering across modules Advanced querying with configurable search/sort, inc. custom fields Flexible invoicing with custom taxes, fields, and variable-based numbering In-house Vue component library (tabs, autocompletes, inputs, etc.) Find everything about this at https://parthparmar.dev/portfolio/deskmint
0
57