konekt / concord
Concord is a Laravel Extension for building modular Laravel Applications
Installs: 1 101 783
Dependents: 76
Suggesters: 1
Security: 0
Stars: 230
Watchers: 16
Forks: 14
Open Issues: 4
pkg:composer/konekt/concord
Requires
- php: ^8.1
 - illuminate/console: ^10.0|^11.0|^12.0
 - illuminate/support: ^10.0|^11.0|^12.0
 - konekt/enum: ^2.1|^3.0|^4.0
 - konekt/enum-eloquent: ^1.7
 
Requires (Dev)
- orchestra/testbench: ^8.0|^9.0|^10.0
 - phpunit/phpunit: 9 - 11
 
- dev-master / 2.x-dev
 - 1.x-dev
 - 1.16.0
 - 1.15.0
 - 1.14.0
 - 1.13.1
 - 1.13.0
 - 1.12.0
 - 1.11.0
 - 1.10.x-dev
 - 1.10.2
 - 1.10.1
 - 1.10.0
 - 1.9.x-dev
 - 1.9.0
 - 1.8.x-dev
 - 1.8.0
 - 1.7.x-dev
 - 1.7.0
 - 1.6.x-dev
 - 1.6.0
 - 1.5.x-dev
 - 1.5.1
 - 1.5.0
 - 1.4.x-dev
 - 1.4.0
 - 1.3.x-dev
 - 1.3.1
 - 1.3.0
 - 1.2.0
 - 1.1.0
 - 1.0.0
 - 0.9.10
 - 0.9.9
 - 0.9.8
 - 0.9.7
 - 0.9.6
 - 0.9.5
 - 0.9.4
 - 0.9.3
 - 0.9.2
 - 0.9.1
 - 0.9.0
 
This package is auto-updated.
Last update: 2025-10-31 00:38:20 UTC
README
Concord is a Laravel Extension that helps to build Modules for Laravel Applications on top of Laravel's built-in Service Providers.
Concord at first is a Laravel package. It also offers some conventions that help you to better structure complex systems.
Version Compatibility
| Laravel | Concord | 
|---|---|
| 5.4 | 1.0 - 1.3 | 
| 5.5 | 1.0 - 1.8 | 
| 5.6 | 1.1 - 1.8 | 
| 5.7 | 1.3 - 1.8 | 
| 5.8 | 1.3 - 1.8 | 
| 6.x | 1.4 - 1.10 | 
| 7.x | 1.5 - 1.10 | 
| 8.x | 1.8 - 1.11 | 
| 9.x | 1.10.2 - 1.15 | 
| 10.x | 1.13+ | 
| 11.x | 1.14+ | 
| 12.x | 1.16+ | 
Basics
Modular Architecture is exactly what you think it is - a way to manage the complexity of a problem by breaking them down to smaller manageable modules. -- Param Rengaiah
Concord itself (this library) manages the modules.
Concord modules are isolated fractions of the business logic, built around a single topic.
There are two kinds of modules from the usage perspective:
- in-app modules,
 - external modules.
 
Concord is not aware of this difference at all, but they represent two different approaches of modularization.
In-app Modules
- They are part of the application's codebase;
 - are located in 
app/Modules/<ModuleName>; - being decoupled is a less strict requirement;
 - code reuse and customization is not an aspect.
 
External Modules
- They are libraries,
 - are typically managed with composer, thus they live in the 
vendor/folder; - should be as decoupled as possible;
 - contain basic or boilerplate functionality for applications;
 - they are designed to be used by multiple, different applications;
 - their behavior is subject to customization in the application.
 
Either module types are always coupled to Laravel and Concord;
Installation
Refer to the Installation Section of the Documentation.
Create Your First Module
php artisan make:module ShinyModule
This will create a very basic in-app module in the app/Modules/ShinyModule folder.
In order to activate the module add it to the config/concord.php file:
return [ 'modules' => [ App\Modules\ShinyModule\Providers\ModuleServiceProvider::class ] ];
Documenatation
See the Concord Documentation for all the nasty details ;)
Plans For Version 2.0
- Artisan Console command names will be de-branded (eg. 
concord:modules->module:list) - The central 
config/concord.phpfile will be eliminated, or split:- modules can specify their own config file name (like normal Laravel packages);
 - therefore several modules can share config files (see vanilo.php);
 - if we keep concord.php, then it'll contain concord specific settings.
 
 - Modules will be loaded as normal packages, using auto-discovery instead of listing modules with concord.
 - Custom names for service providers eg. CartServiceProvider instead of ModuleServiceProvider.
 - Question to the prior item is how to do the same with in-app modules.
 - Re-think the concept of boxes vs. modules.
 - Remove surplus items from Documentation.
 - Remove helpers (?).
 - Remove custom view namespace support.
 - Will we ever use Controller overriding?
 - Add make:request, make:model, make:enum commands that scaffold with interface, proxy etc.
 - Fix AddressType -> address_type kind of style problem in route parameters